[boost] [DateTime] New US DST Rules & Timezones In General

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2007-01-11 08:54:25

I'm in the process of testing/fixing applications in light of the new
DST rules that begin this year in the US (see
http://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005#Change_to_daylight_saving_time).
 In the process of doing this, I found a hard-coded posix_time_zone
specification in one of my libraries that I've had to correct for
these new rules.

As a result of this exercise, I'm once again struck by what seems to
me like an overly rigid treatment of timezones in Boost.DateTime.  The
deficiencies I see in the out-of-the-box implementation are as
follows:

* No built-in support for multiple DST rules within a single zone.
Ideally one should be able to calculate the localtime equivalent of
any datetime in history with the appropriate rules that were in effect
*at that time*.  I've updated my version of the Eastern
Standard/Daylight Time for the new 2007 rules, but if I use this new
set of rules for historic datetimes, I will get incorrect results when
converting to/from UTC.

* Does not make use of system time facilities for localtime
conversions.  I'm not sure how Windows deals with timezone concepts,
but most C libraries on UNIX make use of "tzfile(5)" data files (See
http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=tzfile) to drive
the "gmtime" and "localtime" functions.  Oversimplifying, these files
store a series of time_t values with associated UTC offsets.  If you
inspect one, you'll see all of the past and projected future daylight
savings switch-overs recorded.  When DST rules change, it is a
relatively simple matter to update these data files, and no
application code needs to change.

* Current DST traits classes (us_dst_trait) and examples are incorrect
for new 2007 DST rules.  But fixing these for 2007 makes them wrong
for historic dates.  Catch-22-y.

I realize it is possible to implement a custom time_zone that uses the
system library facilities, but I'd really like to see something like
this available out-of-the-box.  Unfortunately, I don't think the
time_zone_base interface meshes very well with the C library
localtime/gmtime facilities.  For example implementing
"dst_local_start_time(year)" and "dst_local_end_time(year)" might
require some care given the C library interfaces.

Without implementing a custom time_zone, users are left with one and
only one rule they can use, and this means that fixing their timezone
specifications for 2007 breaks them for historic dates.  I'm not sure
if this is concerning for others, but I find it extremely troublesome.

-- 
Caleb Epstein