Re: [boost] [date_time] timezone database

From: boost_at_[hidden]
Date: 2007-01-12 09:16:11

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

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.

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.

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

> > It seems to me that the easiest way to do this would
> > be to use the files generated from the zoneinfo files by zic.
> >
> > A time zone database would be specified by the path to a directory
> > structure containing one or more files produced by zic.  On many
> > Unix-style systems these files already exist, and the tool (zic)
> > exists to produce them for others.
>
> Thx for this pointer, somehow I was not aware of this tool -- although at this> stage I'm not sure how this would help.  The library uses a csv file for data.>   This is for simplicity, portability, and customizability.  The portability
> issue is something that is particularly problematic.  Windows and common *nix
> systems have very different approaches to the timezone data which can't really> be unified easily.  Even among Linux systems there's a heterogeneity of
> solutions even though the 'basic approach' is common.  The bottom line is that> it seemed much more practical to me to provide a single easily editable file
> that application developers could customize and be sure had the desired data.
> Another reason for the csv approach was to provide an easily editable file
> that people could customize for their own purposes.  So, for example, if they
> need a tz database with only a few entries they could trivially use common
> tools (open office, excel, emacs) to change the file.

The zoneinfo data base is a relatively easily edited file, or series
of files.  Furthermore, it is constantly updated, with new changes
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.

> All that said, the library is specifically designed to allow for users that
> have more specific needs to write their own derivative of time_zone to provide> for historic information or other time zone features that go beyond basic
> needs.  A new csv file file form could certainly be created that provides for
> historic dates.
>
> 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.