Re: [boost] [date_time] timezone database

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-01-11 10:06:39

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.

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

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.

Jeff