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