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