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.
> 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?
>> 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
>> 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()
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk