On Tue, 11 Jan 2005 19:59:35 -0700, Jeff Garland
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