RE: [Boost-Users] Re: Newbie help with date_time

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?

I'm suprised by this -- I think it should work. But I agree this isn't the best approach.

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.

Agree, for sure.

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.

I'm not sure you are missing something, but perhaps the library is. This constructor is private because I've seen too many errors in the past with programmers using the raw tick counts.

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

It might be that you have found something that the library hasn't anticipated.

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 like the idea. What if we called them round_up and round_down instead? I don't have time to do anything with this today, but I can probably add this in the next few days. 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.

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...

FYI the Change History document 'Changes.html' for Date/Time is missing from both the Boost website and the archived docs, and the

Yes, this just got patched on the website.

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>

Thanks, I'll put these on the todo fix list. Jeff