Constructing boost::posix_time::ptime from "flat" time?
I am having a hard time figuring out how to construct a ptime from a "flat" time (i.e., some number of time units since some epoch) other than a time_t. For instance, we have a lot of software here at work that represents time as a double-precision floating point number of seconds since 1/1/1904 00:00:00 GMT. As you can imagine, any sensible number is bigger than a 32-bit integer. I would like to be able to construct a ptime something like this: ptime p(date(1904, Jan, 1), microsec(boost::int64_t(float64_time * 1000000.0)); ...or even better... ptime p(date(1904, Jan, 1), float64_time); Problem is, it seems the constructors to most time_duration types use longs, even if they use int64's internally. I can't get the above example to work with any time past 12/31/1904 23:24:12, which just happens to be 0x80000000 microseconds past 1/1/1904. Another thing I would like to do is construct a ptime from a Win32 FILETIME, which is an int64 number of 100ns intervals since 1/1/1601. Something like this: ptime p(date(1601, Jan, 1), nanosec(100 * fileTime)); Is there a better way to do this? I am using MSVC 6.0 SP5 with Boost 1.31.0. -Charles
On Tue, 10 Feb 2004 11:31:29 -0600, charles.crain wrote
I am having a hard time figuring out how to construct a ptime from a "flat" time (i.e., some number of time units since some epoch) other than a time_t. For instance, we have a lot of software here at work that represents time as a double-precision floating point number of seconds since 1/1/1904 00:00:00 GMT. As you can imagine, any sensible number is bigger than a 32-bit integer.
Yep.
I would like to be able to construct a ptime something like this:
ptime p(date(1904, Jan, 1), microsec(boost::int64_t(float64_time * 1000000.0));
...or even better...
ptime p(date(1904, Jan, 1), float64_time);
Problem is, it seems the constructors to most time_duration types use longs, even if they use int64's internally. I can't get the above example to work with any time past 12/31/1904 23:24:12, which just happens to be 0x80000000 microseconds past 1/1/1904.
Yes, that is at least partially because the library supports multiple internal representation options -- not all of which are int64 internally. So to do this correctly you will have to subtract the date part out of the offset, construct the date, and then add the time duration. Give me a day or so to work on an example.
Another thing I would like to do is construct a ptime from a Win32 FILETIME, which is an int64 number of 100ns intervals since 1/1/1601. Something like this:
ptime p(date(1601, Jan, 1), nanosec(100 * fileTime));
Is there a better way to do this? I am using MSVC 6.0 SP5 with Boost 1.31.0.
No. It looks like we are going to need to change the interface to support this correctly. This would be nice to add to the library as I expect I'll be needing this myself at some point :-) Jeff
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). 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. -- Jeremy Maitin-Shepard
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
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
[snip]
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."
I cannot be certain because it seems that a significant portion (the more generic portion) of the library is not documented, except for the doxygen-generated files, but my impression is that ptime represents a time in a specific time zone. Also, while the more generic portions of the library seem to support various user-specified precisions, ptime (the only time-point representation documented) is limited to a specific implementation-defined precision.
[snip]
-- Jeremy Maitin-Shepard
On Thu, 12 Feb 2004 18:41:03 -0500, Jeremy Maitin-Shepard wrote
I cannot be certain because it seems that a significant portion (the more generic portion) of the library is not documented, except for the doxygen-generated files,
Well, if you have questions just ask. There are many reasons why there isn't more documenation of the generic part of the library -- the primary ones being I don't believe I'm done modifying it and that it is an implementation detail for 98% of the users.
but my impression is that ptime represents a time in a specific time zone. Also, while the more
No, ptime is a non-adjusted time representation. So it can be used to represent either UTC or a local time. However, if it is a local time the user is required to keep that information externally. In the next release of the library there will be a local_date_time and time_zone classes that provide full support for local time representations.
generic portions of the library seem to support various user- specified precisions, ptime (the only time-point representation documented) is limited to a specific implementation-defined precision.
Yes, it is currently limited to the 2 specified resolutions. However, I have helped, and will help anyone that needs other resolutions. There is some refactoring and that needs to be done before this is offered as a documented feature of the library. Jeff
participants (3)
-
charles.crain＠ni.com -
Jeff Garland -
Jeremy Maitin-Shepard