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<time_duration, time_res_traits>(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