Re: [boost] Constructing boost::posix_time::ptime from "flat" time?

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-02-11 23:37:47

On Wed, 11 Feb 2004 10:15:55 -0500, Jeremy Maitin-Shepard wrote
> It seems it might be more useful if the interface of the date-time
> library were changed to either use a single precision (milliseconds 
> or microseconds) or allow the precision to be specified by the user 
> as a template parameter (i.e. the user could specify seconds,
>  milliseconds, microseconds, or nanoseconds).  

Yes, I believe a for this can be written.  The interface would be something like:

ptime time_from_epoch(date epoch_of_time, 
                      boost::int64_t raw_time,
                      boost::int64_t ticks_per_second) 

>The actual precision 
> of the current time clock would of course depend on the platform-
> specific facilities available for accessing the system time.  Then 
> the primary representation of a time duration would be the total 
> number of seconds/milliseconds/microseconds/nanoseconds and the primary
> representation of a time point could be a time duration since a fixed
> epoch in a fixed time zone, i.e. 1970-01-01 00:00:00.0000 UTC.  This
> would allow convenient separation of the calendar handling from the
> time representation, and the time representation could be used 
> without the calendar handling.

The library is already designed in this fashion (except that the epoch is
1400-01-01 00:00:00).  From the docs "A Clock Device is software component
(tied to some hardware) that provides the current date or time with respect to
a time system. A clock can measure the current time to a known resolution
which may be higher or lower than a particular time representation."

http://www.boost.org/libs/date_time/doc/index.html#domain 

The only reason that I'm looking into this a bit more carefully before I
respond is that to write time_from_epoch is going to require some redundant
calculation.  So I'm trying to find a way to eliminate the extra calculations
without exposing the internal time representations improperly.  Exposing the
internal representation is dangerous since the library already uses multiple
internal implementations and is designed to allow new ones to be developed
without redeveloping the whole library...

Jeff