In article
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