Re: [boost] [date_time] timezone database

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-01-12 18:16:47

boost_at_[hidden] wrote:
>> boost_at_[hidden] wrote:
>>> I believe others have pointed out that the time zone database would be
>>> much more useful if for each time zone one could have multiple
>>> daylight saving rules, each with its own start and stop time of
>>> applicablity.
>> I'm not sure it would be *much more useful*.  Before the change in US rules,
>> only one person has asked for this feature in the last couple years...not
>> exactly overwhelming demand.  In addition, there is a cost in memory and
>> complexity to be paid.
> 
> I recently had to become knowledgeable about time zones for my job,
> and I have discovered that most people don't know much about them, so
> I'm not suprised at the lack of demand.

I agree, most people don't understand them but I don't think that's why 
there's been a lack of demand.

> There are two problems that I know of with time zone systems that
> don't provide for multiple daylight saving rules and times of their
> applicability.
> 
> First, using a single daylight saving rule will sometimes produce an
> incorrect result on dates older than the period of applicability the
> rule.  Thus any program that uses such a rule and has to deal with
> dates other than fairly recent ones will occasionally malfunction in
> dealing with many, if not most time zones.

Right.  This only applies to applications that actual store dates to a file or 
database or subtract from current time.

> Second, there is an administrative problem for a system that is in
> constant use:  when do you change the rule?  With the multiple rule
> kind of database you can put in the new rule well ahead of when it is
> needed, at any convenient time.

This is a difficult problem which the library can never directly solve and 
hence is left to the application.  Once the rules are updated, the answers 
will likely change.  Which, btw, is one of the reasons that all time-based 
calculations should almost always be stored in UTC.

> In short, the one daylight saving rule approach cannot be expected to
> function correctly for some applications.

No disagreement.

>>> It seems to me that the easiest way to do this would
>>> be to use the files generated from the zoneinfo files by zic.
>>>
> The zoneinfo data base is a relatively easily edited file, or series
> of files.  Furthermore, it is constantly updated, with new changes

It's a set of files and in my view it's quite difficult to understand because 
it uses 'links' or references which make it quite difficult to understand. 
But I agree it is updated.

> being added far in advance of their need.  The new US rules have been
> included for some time, I believe.  It seems to me it would be easier,
> and more likely to be correct for someone who only wants a subset of
> all the rule to take the zoninfo files and cut out the parts which
> they dont want, rather than create a new database from scratch.

I agree, but I believe the current csv is much easier to understand.

>> So to be clear, I'm not opposed to upgrading the library with other approaches
> to reading different kinds of zone files, supporting historical dates, etc.
>> There just hasn't been much of a request until recently.  As I've said to
>> others, I'm willing to help other that want to contribute.
> 
> I hope the above comments don't sound too negative.  I appreciate all
> the work that has gone into the date_time library.  I know just enough
> about some of the problems to realize how complicated a subject it is.

Not at all.  The timezone problem is a nasty one which probably explains why 
there hasn't been a good clear standard to deal with it and why every OS does 
it differently.  I'm sorry that the current library doesn't provide an answer 
for applications that need historic times out of the box, but it will get 
their eventually now that a couple people have expressed a strong need.  I 
still think it's a very small minority of the apps using date-time that are 
impacted.

Jeff