Maybe you could be a little bit more specific about how this is 'failing' -- runtime or compile time...

My apologies. I stated my problem in haste, and made a poor show of it. Let me try harder. 1. I believe I need to do arithmetic on time lengths using the % operator. So I need to get at some sort of integer that represents them. I have been using the .ticks() to get my integer out and the nanosec() class to put things back into periods. However I notice that using namespace boost::posix_time; using namespace boost::gregorian; // ... 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? 2. Even if it worked, I hate using nanosec() for this job anyway. If I am pulling something out with ticks(), I feel I should be putting it back as ticks(). So that I could change to the cheap and cheerful microsecond only resolution and have it still work. I suspect maybe I could if I had access to a private constructor of yours explicit time_duration(tick_type ticks) : date_time::time_duration(ticks) {} but obviously this is Not For Me. So I suspect that I am missing something. 3. Furthermore, I have a suspicion that my technique is all wrong, and that somewhere there is a Much Better Way which the libaray anticipates. Let me set out my ideal, as a punter, merrily ignoring the constraints of real life. I would like to see (say) methods of the ptime class, floor() and ceil(), that worked like this ptime t1(date(2002,Jan,10), time_duration(5,27,31)); // t1 is 2002/01/10 05:27:31 ptime t2(t1.floor(minutes(5)); // t2 is 2002/01/10 05:25:00 // ie previous five minute boundary ptime t3(t1.ceil(seconds(10)); // t3 is 2002/01/10 05:27:40 // ie next 10 second boundary 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. TIA for any pointers. --- FYI the Change History document 'Changes.html' for Date/Time is missing from both the Boost website and the archived docs, and the typo 'tommorrow' for 'tomorrow' has snuck in as a variable name in various example programs - see Google for details. C++ programming is beyond me, but proof reading I can do <g> Regards Will Watts

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