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

From: Jeff Garland (jeff_at_[hidden])
Date: 2003-03-21 08:51:15

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