[boost] Re: date_time -> ptime

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-04 19:25:41

"Jeff Garland" <jeff_at_[hidden]> writes:

> On Wed, 03 Sep 2003 17:09:08 -0400, Philip Miller wrote
>> David Abrahams wrote:
>> 
>> > I'm trying to get a ptime relative to 1/1/1970, so I did:
>> >
>> >     using namespace boost::date_time;
>> >     ptime d;
>> >     ...
>> >     boost::posix_time::time_duration since_1970 = d - 1/Jan/1970;
>> >
>> > Error.
>> >
>> > Since it is a completely lossless conversion (like an upcast), I'd
>> > like to see boost::date -> boost::posix_time::ptime implicit
>> > conversions added.
>>
>> Can you elaborate on the problem?  I, too, am doing lots of 
>
> I believe that Dave is asking for a non-explicit constructor for
> ptime from date.  

Yep.

> But he is also using an expression template
> extension to allow the 1/Jan/1970 to compile.

No, actually I was just remembering it from Joel's exchages with you
and assuming that it was in the library.  Unfortunately it is not and
I had to go back to the more-verbose date(1970, 1, 1).

>> conversions between the boost::date_time library date, ptime, and 
>> duration instances with the conventional unix/posix dawn of time,
>>  1/1/1970.  To my knowledge (perhaps in ignorance), I have had no 
>> problems using constructs similar to
>> 
>> ptime time0( date(1970, 1, 1 ) );
>> ptime t1;
>> ...
>> time_duration dt = t1 - time0;
>> 
>> Is the problem that you want to do this with date instances and not
>> time instances?
>
> Exactly.

Yep.

>> With regards to another posting you made, I also work to work with 
>> in sub-second time precision and have had a problem understanding 
>> the nuances of clock ticks/resolutions.  As a simple user I have not 
>> had many (if any) problems getting the library to do what I want,
>>  given that my assumption that time_duration::fractional_seconds 
>> returns microseconds is correct.  If/when this assumption becomes 
>> invalid (i.e., date_time changes its internal representation for 
>> msvc or I work on a platform that uses nanoseconds for 
>> fractional_seconds), then I will be in trouble and have to fix a few 
>> places spots in my code.  So, I would like to see a standard 
>
> You control the resolution when you compile as described in the docs
> so there isn't a change from platform to platform unless you set up
> your makefiles differently between platforms.

It's usually possible to get any effect you want, even if the
resolution should change, using seconds(1).ticks() to find the
resolution.

>> time_duration accessor that returns microseconds rather than the
>> compile-time dependent fractional_seconds.
>
> I think what you want is really 'total_microseconds', right?  hours,
> minutes, and seconds provide a 'normalized count' which is really
> for 'breakdown printing' (eg: 10:09:08). And presumably if your
> time_duration was using nanoseconds you might what
> total_microseconds to round up/down appropriately?

  x.ticks() * 1e6 / seconds(1).ticks()

does it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com