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

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-01-11 10:22:14

Caleb Epstein wrote:
> 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.

Yep, all true.  But until the switch in US rules there has been basically zero 
demand for this feature.  My perception is that the majority usage of tz 
conversion usage is to convert the current time or times in the near future to 
a local time.

> * 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.

I've studied these files in some depth in the past.  The basic issue is 
portability.  They certainly aren't portable to Windows without major 
administration effort by users.  The Windows approach, overall, is quite 
different than the Unix approach btw. And on my several Linux machines these 
files aren't handled consistently due to difference in the C interfaces and 
the installation approaches.  So as I said in the other email it seemed much 
easier to provide a trivially updateable single file for app developers to 
manage and that would enable them to ensure consistent rules as needed for 
their application.

> * 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.

Yep.  Of course you could copy the source and make new traits classes for the 
new rules.  It's ugly but if you have limited needs  and are currently using 
the 'compiled in approach' it might be the best solution. If you are just 
using 'current time' conversions you want an updated trait.

> 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

Well, me too, now that there is a sudden demand for this feature...

> 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.

I still believe my conclusion about the inadequacies of the C api were 
correct.  We'd be better off concentrating on upgrading the csv file/library 
to support historic dates.

> 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.

Well, there's at least 2 of you now.

Jeff