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