Re: [Boost-users] Date-Time question on seconds since epoch

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-01-12 22:29:33

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