Re: Newbie help with date_time

From: Will Watts (yg-boost-users_at_[hidden])
Date: 2003-03-21 12:58:00

In article <LPBBLOEIMCKBCMMHJMGAMEGDENAA.jeff_at_[hidden]>, 
Jeff Garland wrote:

> > LONGLONG res = 1548000000000;
> > LONGLONG otherres = nanosec(res).ticks(); 
> > if (otherres != res)
> >  TRACE("Eeek\n"); // Send to debug window
> > 
> > puts "Eeek" on my debug console. So nanosec() does not work as the
> > inverse of ticks(). (Perhaps it takes a long?) So having done
> > arithmetic on a value obtained from ticks(), how should I be poking it
> > back in?
> 
> I'm suprised by this -- I think it should work. 

Well for the record this is with MS VC6 and according to the debugger, 
otherres contains 1811773440 afterwards. Or to express that in another way

res      = 0x000001686bfd7800
otherres = 0x000000006bfd7800

which is rather suggestive, is it not? 

Treacherous chaps, integer types.

> I like the idea.  What if we called them round_up and round_down 
> instead?  

In the circs, I think I can see my way to allowing you to name your own 
library. <g> 

Seriously - if you think you can do anything soon, that would be fab. I 
undertake to put it into this 'ere app and stress it a bit.

> BTW, I have written a 'multi-precision' time point based
> on ptime for another user that keeps track of whether the ptime
> actually represents a day, minute, second, etc.  This might be another
> approach to this problem. 

Whatever you think is best.

> > I would like this to work from multiples of days down to multiples of
> > nanoseconds. I am prepared to specify an origin - eg 1/1/1970 - as a
> > second parameter which usually defaults, and I certainly do not wish
> > to be tripped up by the scary sounding leap seconds that you mention
> > in your docs. 
> >
> > Don't want much, do I? :-) But it's a bit similar to the algorithm
> > stuff you do with dates, so I thought it might be in there somewhere.
> 
> I'm not sure what you are asking for here...

When you round, you must be doing so with respect to some basetime, which 
is 0. This is your choice not mine. So that if I ask for 

ptime t2(t1.round_down(hours(24 * 7));

then t2 will always turn out to be a Wednesday (or whatever it happens to 
be) because your time zero happens to be a Wednesday. I should like always 
to get a Thursday, because I am a member of TheWeekBeginsOnThursday cult.

So I'm suggesting there be an optional second parameter, or an overloaded 
version, where one can specify one's own date as a base

ptime MyBeginningOfTime; // Intitalised to some a Sunday long ago
ptime t2(t1.round_down(hours(24 * 7), MyBeginningOfTime);

Or if I wanted the time of the most recent log entry since blast off, where 
log entries are made at 30 second intervals of elapsed time from blast off

ptime BlastOff;  
ptime l(second_clock::universal_time().round_down(seconds(30), BlastOff);  

Of course, there are other ways of doing this stuff by fiddling with the 
result. If you say it is over-egging the pudding, I'm not arguing. It just 
occurred to me that once you start in on this kind of arithmetic, it would 
be jolly lovely to keep it all in the library and out of my face.

Will