Date-Time question on seconds since epoch
I'd like to determine the total number of seconds between a date and the epoch ('00:00:00 1970-01-01 UTC'), The date can be in a timezone that has daylight savings. The date should be converted to UTC, with appropriate daylight savings adjustments made, and then the epoch subtracted from it. This should mirror the unix GNU 'date' utility, which can be run as: % TZ="America/New_York" date --date='2004-10-04 12:14:32' +%s 1096906472 I've looked at the doc, but it's not clear how to do this. Could someone give me a few pointers, please? Thanks. Bill
On Tue, 11 Jan 2005 07:26:20 -0600, Bill Lear <rael@zopyra.com> wrote:
I'd like to determine the total number of seconds between a date and the epoch ('00:00:00 1970-01-01 UTC'), The date can be in a timezone that has daylight savings. The date should be converted to UTC, with appropriate daylight savings adjustments made, and then the epoch subtracted from it. This should mirror the unix GNU 'date' utility, which can be run as:
% TZ="America/New_York" date --date='2004-10-04 12:14:32' +%s 1096906472
I've looked at the doc, but it's not clear how to do this. Could someone give me a few pointers, please?
I would make use of the standard library facilities timelocal or timegm to convert a struct tm to time_t format. The former assumes the time is expressed in local time (as specified by the TZ environment variable or via tzset) and the latter assumes it is in GMT. The support for timezone conversions in Boost.DateTime is rudimentary at best and does not currently make use of operating system facilities like the zoneinfo database. -- Caleb Epstein caleb dot epstein at gmail dot com
On Tue, 11 Jan 2005 09:22:06 -0500, Caleb Epstein wrote
On Tue, 11 Jan 2005 07:26:20 -0600, Bill Lear <rael@zopyra.com> wrote:
I'd like to determine the total number of seconds between a date and the epoch ('00:00:00 1970-01-01 UTC'), The date can be in a timezone that has daylight savings. The date should be converted to UTC, with appropriate daylight savings adjustments made, and then the epoch subtracted from it. This should mirror the unix GNU 'date' utility, which can be run as:
% TZ="America/New_York" date --date='2004-10-04 12:14:32' +%s 1096906472
I've looked at the doc, but it's not clear how to do this. Could someone give me a few pointers, please?
I would make use of the standard library facilities timelocal or timegm to convert a struct tm to time_t format. The former assumes the time is expressed in local time (as specified by the TZ environment variable or via tzset) and the latter assumes it is in GMT.
The support for timezone conversions in Boost.DateTime is rudimentary at best and does not currently make use of operating system facilities like the zoneinfo database.
From the timezone you can determine the utc offset and dst_offset as well as
This is true, but in 1.33 this will be vastly improved. In fact, the experimental version of this is already in CVS. Have a look at libs/date_time/test/local_time/testtz_database.cpp. There you will find testcode for a timezone database feature that will allow you do convert directly based on a regional timezone specification (there's also a posix timezone specification class). Bascially you load in the timezone data from a csv file -- one is provided in the libs/date_time/data/ directory that derives from the timezone database project. tz_database tz_db; tz_db.load_from_file("../data/date_time_zonespec.csv"); boost::shared_ptr<time_zone_base> nyc_test = tz_db.time_zone_from_region("America/New_York"); the start time for dst in a given year. All of this is integrated with a local_date_time class that can hold the time as well as the timezone pointer (see testlocal_time.cpp in the same directory). All this is preliminary as it doesn't have docs and hasn't been tested on lots of platforms, but if you have a reasonably modern c++ compiler it should work. I can't guarantee that the interface won't change before the 1.33 release, but things are pretty stable at this point. HTH, Jeff
On Tue, 11 Jan 2005 09:22:06 -0500, Caleb Epstein wrote Not sure what happened to my reply 12 hours ago, but I'll try again...
On Tue, 11 Jan 2005 07:26:20 -0600, Bill Lear <rael@zopyra.com> wrote:
I'd like to determine the total number of seconds between a date and the epoch ('00:00:00 1970-01-01 UTC'), The date can be in a timezone that has daylight savings. The date should be converted to UTC, with appropriate daylight savings adjustments made, and then the epoch subtracted from it. This should mirror the unix GNU 'date' utility, which can be run as:
% TZ="America/New_York" date --date='2004-10-04 12:14:32' +%s 1096906472
I've looked at the doc, but it's not clear how to do this. Could someone give me a few pointers, please?
I would make use of the standard library facilities timelocal or timegm to convert a struct tm to time_t format. The former assumes the time is expressed in local time (as specified by the TZ environment variable or via tzset) and the latter assumes it is in GMT.
The support for timezone conversions in Boost.DateTime is rudimentary at best and does not currently make use of operating system facilities like the zoneinfo database.
Caleb is right, the released functionality in date-time makes this difficult to do. However, the current CVS actually has everything you need. I wrote the following small program that does the calculation using new features which will be released as part of 1.33: //convert.cpp #include "boost/date_time/local_time/local_time.hpp" #include <iostream> int main() { using namespace boost::gregorian; using namespace boost::local_time; using namespace boost::posix_time; tz_database tz_db; tz_db.load_from_file("date_time_zonespec.csv"); boost::shared_ptr<time_zone_base> nyc_tz = tz_db.time_zone_from_region("America/New_York"); date in_date(2004,10,04); time_duration td(12,14,32); // construct with local time value -- create not-a-date-time // if invalid (eg: in dst transition) local_date_time nyc_time(in_date, td, nyc_tz, local_date_time::NOT_DATE_TIME_ON_ERROR); std::cout << nyc_time << std::endl; ptime time_t_epoch(date(1970,1,1)); std::cout << time_t_epoch << std::endl; time_duration diff = nyc_time.utc_time() - time_t_epoch; std::cout << "Seconds diff: " << diff.total_seconds() << std::endl; return 0; } Output: Mon Oct 4 12:14:32 2004 EDTEDT 1970-Jan-01 00:00:00 Seconds diff: 1096906472 I see there is a bug in the output code right now that prints the short time zone abbreviation twice right now. We are in the process of a major I/O overall. But anyway, if you are willing to work with 'alpha' code with no docs you can use it now. I say alpha code, but there are already pretty complete tests in the tests/local_time directory... BTW, the tz_database class is reading a file you will find in cvs at libs/date_time/data/date_time_zonespec.csv. This CSV file contains a dump of time zone database data into a form that is handing for reading, porting, and editing. This is what allows the regional time_zone specification that contains all the dst rules, etc. HTH, Jeff
On Tue, 11 Jan 2005 19:59:35 -0700, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
BTW, the tz_database class is reading a file you will find in cvs at libs/date_time/data/date_time_zonespec.csv. This CSV file contains a dump of time zone database data into a form that is handing for reading, porting, and editing. This is what allows the regional time_zone specification that contains all the dst rules, etc.
From what I can tell, the functional approach you have doesn't allow for oddball historial anomalies like the ones shown below. This is
It might be nice to be able to make use of the considerable library of "tzfile" data available on many UNIX systems. This data is invaluable for getting accurate localtime values for historical dates (e.g. when DST rules were in flux). partial output from a Perl script (attached) which dumps tzfile-formatted data (see http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=tzfile for the gory details): [...] Mon Feb 9 03:00:00 1942 => 2 Tue Aug 14 19:00:00 1945 => 3 [...] ttinfo[2]: gmtoff=-14400 isdst=1 abbrind=8 ttinfo[3]: gmtoff=-14400 isdst=1 abbrind=12 abbrevs: EDT, EST, EWT, EPT So for a period of time from Feb 9 1942 to Aug 14 1945, the East Coast of the US was in "EWT" which I can only assume stands for "Eastern War Time". The down-side of the tzfile data is that there is a big lookup table of all DST changeovers from 1918 until 2037. Clearly the functional approach is cleaner in the case where DST rules have been standardized. -- Caleb Epstein caleb dot epstein at gmail dot com
On Wed, 12 Jan 2005 22:00:58 -0500, Caleb Epstein wrote
It might be nice to be able to make use of the considerable library of "tzfile" data available on many UNIX systems. This data is invaluable for getting accurate localtime values for historical dates (e.g. when DST rules were in flux).
My goal was to write something that is portable, so making use of this isn't really helpful. But I believe the timezone abstraction should be sufficient to allow others to use other api's to make these adjustments if they desire.
From what I can tell, the functional approach you have doesn't allow for oddball historial anomalies like the ones shown below. This is partial output from a Perl script (attached) which dumps tzfile-formatted data (see http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=tzfile for the gory details):
[...] Mon Feb 9 03:00:00 1942 => 2 Tue Aug 14 19:00:00 1945 => 3 [...] ttinfo[2]: gmtoff=-14400 isdst=1 abbrind=8 ttinfo[3]: gmtoff=-14400 isdst=1 abbrind=12 abbrevs: EDT, EST, EWT, EPT
So for a period of time from Feb 9 1942 to Aug 14 1945, the East Coast of the US was in "EWT" which I can only assume stands for "Eastern War Time". The down-side of the tzfile data is that there is a big lookup table of all DST changeovers from 1918 until 2037. Clearly the functional approach is cleaner in the case where DST rules have been standardized.
Yes, I'm aware of all this historical 'fun and games' with the dst rules. And again, I believe the time zone base class provides a sufficient abstraction to plug in these adjustments should someone choose to deal with the performance and other costs associated with handling all the historical timezones. My design choice was to focus on providing what I believe to be a couple practical solutions (regional and posix string specs) to the time zone adjustment issue for applications that deal with the current time space. Part of this comes from my belief that there are a large number of applications that need to do local adjustments for the current times and a only few applications that need to go back in time. Anyway, if you have an application for the historical cases I'm willing to work with you on writing timezone derivative and adaptor for these API's. I'd like to prove that the date-time can be extended for these cases even if it can't be portably supported. Jeff
On Wed, 12 Jan 2005 20:29:33 -0700, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Part of this comes from my belief that there are a large number of applications that need to do local adjustments for the current times and a only few applications that need to go back in time.
Fair enough. I suspect you're probably right that getting a super-accurate local time for some date before the time_t epoch is not likely to be a very common requirement. -- Caleb Epstein caleb dot epstein at gmail dot com
On Tue, 11 Jan 2005 19:59:35 -0700, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
BTW, the tz_database class is reading a file you will find in cvs at libs/date_time/data/date_time_zonespec.csv. This CSV file contains a dump of time zone database data into a form that is handing for reading, porting, and editing. This is what allows the regional time_zone specification that contains all the dst rules, etc.
From what I can tell, the functional approach you have doesn't allow for oddball historial anomalies like the ones shown below. This is
It might be nice to be able to make use of the considerable library of "tzfile" data available on many UNIX systems. This data is invaluable for getting accurate localtime values for historical dates (e.g. when DST rules were in flux). partial output from a Perl script (attached) which dumps tzfile-formatted data (see http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=tzfile for the gory details): [...] Mon Feb 9 03:00:00 1942 => 2 Tue Aug 14 19:00:00 1945 => 3 [...] ttinfo[2]: gmtoff=-14400 isdst=1 abbrind=8 ttinfo[3]: gmtoff=-14400 isdst=1 abbrind=12 abbrevs: EDT, EST, EWT, EPT So for a period of time from Feb 9 1942 to Aug 14 1945, the East Coast of the US was in "EWT" which I can only assume stands for "Eastern War Time". The down-side of the tzfile data is that there is a big lookup table of all DST changeovers from 1918 until 2037. Clearly the functional approach is cleaner in the case where DST rules have been standardized. -- Caleb Epstein caleb dot epstein at gmail dot com
participants (7)
-
Bill Lear -
Caleb Epstein -
Jeff Garland