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

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

Stephen Turner wrote:
>> -----Original Message-----
>> From: Stephen Turner [mailto:sturner_at_[hidden]] 
>> Sent: 22 December 2006 16:39
>> To: 'boost-users_at_[hidden]'
>> Subject: [date_time] timezone rules for different years
>>
>> For my application, I need to be able to get the local time 
>> of any UTC time in the last five years in any location.
>>
>> As far as I can see, the date_time library doesn't provide 
>> this. The documentation says that date_time_zonespec.csv is 
>> "based on data found in the zoneinfo datebase", but whereas 
>> the zoneinfo database contains historical information about 
>> daylight saving time changes, date_time_zonespec.csv only 
>> seems to allow you to specify a single rule for each 
>> timezone. And I can't find another mechanism to do it.
>>
>> Am I missing something, or is this capability not present? 
>> And if not, is there any plan to add it? Or a workaround? I 
>> anticipate that this will become more of a problem when the 
>> rules for the U.S. change by several weeks next year.
>>
> 
> I'm not sure whether this one got lost in the holiday break, or whether
> there's nobody who's familiar with the internals of this library on this
> list, but let me try again.

Hi Stephen -

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