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
> 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
> * 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
> * 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk