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 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 time_duration accessor that returns microseconds rather than the compile-time dependent fractional_seconds. Phil _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
