Re: [Boost-users] [date_time] timezone rules for different years

From: Matt K (boogerz_at_[hidden])
Date: 2007-02-06 17:54:06

Jeff Garland <jeff <at> crystalclearsoftware.com> writes:

> Yes, sorry I was off the net on holiday for an extended period   Finally 
> getting caught up now...
> 
> > I've been trying to work out how to add the capability to have different
> > timezone rules in different years to the library. It seems to me it's not
> > too hard (although I'm nervous of making such a judgement in code I'm not
> > familiar with). I think all that's needed is:
> > 
> > 1) In class custom_time_zone, the rules should depend on y, rather than
> > there just being one set of rules.
> 
> Since the core of the library uses time_zone as an abstraction, the intent 
> would be to derive from this class and implement one that implements the 
> multi-year timezone rules.  The methods
> 
>    time_type dst_local_start_time(year_type);
>    time_type dst_local_end_time(year_type);
> 
> are the key.  The returned values for these methods would be varied by the 
> year.  Note that you can also derive from the custom_time_zone class and just 
> re-implement these two methods if you so desire.
> 
> Of course that doesn't help with the tz_database as you discuss below.
> 
> > 2) The date_time_zonespec.csv file would have to have extra columns for
> > years a rule applied to. tz_db_base::parse_string would have to parse them,
> > and instead of creating a new timezone for each line, add the rule to the
> > appropriate timezone if it had already been seen once.
> > 
> > Is there anything else that would need to be done?
> 
> I would recommend that this be created as an alternative tz_database class -- 
> something like 'historic timezone database'.  My experience is that must 
> applications don't need the historic data and hence only really care about 
> loading up the current set of rules.  I can see that the library form is not 
> optimum for this as you'd like to reuse most of the current code with slight 
> modifications.  We can work on that.
> 
> > Actually, I think the hardest part would be populating the
> > date_time_zonespec.csv file. Is there already a program to generate that
> > file from the zoneinfo files, or was it done semi-by-hand?
> 
> There was a script somewhere (don't know if I still have it), but it was 
> semi-by-hand.  As you mentioned in another mail you could have a new tz 
> database that could read the tzdb files directly.  Personally, I don't have a 
> use for this or time to implement it myself, but if you are motivated I'm 
> willing to help you through the process and add into the library when it is 
> complete.
> 
> Jeff
> 

I'm wondering if any actual effort is being put into this or if it has died off?

I have some tools that use the boost::date_time libraries.  The upcoming DST 
change from April to March made me realize that I am not accounting for 
historical changes to DST.  It seems to me that even though most programs don't 
care about the historical data going back to 1918, they probably do care about 
the historical changes between 2006/2007.  Any program that references a time 
in Mar. 2006 is going to be wrong if it assumes that new 2007 rules have been 
in effect forever.

Rather than trying to develop a new file format that includes historical rules, 
is there any reason why we can't simply use the zoneinfo database already on 
most POSIX systems?  I need to look more closely at the code to see how all of 
this works, but my first thought was, "Can I just change boost to point 
at /usr/share/zoneinfo instead of the zonespec.csv file?"

-Matt