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.

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

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

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

Jeff
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to