|
Boost Users : |
From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-01-12 22:01:10
On Tue, 11 Jan 2005 19:59:35 -0700, Jeff Garland
<jeff_at_[hidden]> 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.
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).
>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.
-- Caleb Epstein caleb dot epstein at gmail dot com
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net