Re: [boost] [date_time] Time zone improvements

Subject: Re: [boost] [date_time] Time zone improvements
From: Jeff Garland (jeff_at_[hidden])
Date: 2008-12-01 09:08:32

Rutger ter Borg wrote:
> Jeff Garland wrote:
>

This thread is in slow motion...but keeping it going...

>> Very cool :-) One question -- is there a portable solution where a user
>> could deploy a files onto a Windows system or is it a Unix only solution?
> 
> Portable, big endian binary files. 
> 
> The variant I'm proposing is also based on the POSIX standard 
> http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html:

Ok.

> "TZ
>     This variable shall represent timezone information. The contents of the 
> environment variable named TZ shall be used by the [snip] functions, and by 
> various utilities, to override the default timezone. The value of TZ has one 
> of the two forms (spaces inserted for clarity):
>         :characters
>     or:
>         std offset dst offset, rule
> "

Ok.

> The second variant is what's currently in Boost.Date_Time as Posix Time Zone, 
> having a direct specification of the time zone. I'll be talking about the 
> first variant, containing :characters. Although this is implementaiton 
> specific, most POSIX-compatible systems have implemented the Zoneinfo 
> database for this variant, e.g., Linux-based systems, many BSDs, Mac OS X, 
> etc. The :characters point to any other zoneinfo-compatible binary file, 
> either with an absolute or relative path. 
>
> A natural step for changing Boost.Date_Time would be to make changes such that 
> the Posix Time Zone supports both formats. I.e., 
> 
> variant 1) posix_time_zone( ":/etc/localtime" ); or
>                posix_time_zone( ":/usr/share/zoneinfo/Europe/Amsterdam" );
> variant 2) posix_time_zone( "EST-5EDT,M4.1.0,M10.5.0" );
> 
> I think both should work as it is from the same standard, and seems to be a 
> natural and consistent starting point to look at changing the interface. Do 
> you agree?

Ok, again it would be wonderful if this could also be deployed to a properly 
configure Windows system -- preferably without changing the string.

>> Actually, I believe the abstract timezone is able to support this, but
>> there
>> isn't a concrete implementation.  It would be great to have the concrete
>> implementation to prove out the abstraction (obviously from the text below
>> you think there needs to be changes).
> 
> As far as I can tell, the abstract time zone class currently is not able to 
> represent variant 1): the abstract zone class is geared towards a 
> single-lined definition of a time zone, whereas variant 1) may be regarded as 
> a series of definitions, i.e., a map of 
>
> < transition_time_point_in_utc, { gmt_offset, abbreviation, is_dst, ... } > 
> 
> looking up utc_to_local is a matter of doing a lower_bound search on the 
> transition time points. 

Look carefully at the abstract time zone.  It's designed so that when you ask 
for the local_start_time and the local_end_time for dst you need to provide 
the year as a parameter so that subclasses can provide the historic 
conversions -- so it looks like this:

   time_zone_base tz = ...
   ptime t = tz.dst_local_start_time(2008);

But, it's possible that to fully support support Olsen you'll need dst_offset 
and maybe some others to be expanded to support a year parameter as well.  In 
any case I think we should be able to do that in a backward compatible fashion.

> The right-hand side of the map above is widely 
> implemented with a struct called ttinfo. 
> 
> A proposal from my side would be to change the abstract time zone class in 
> such way that it is able to represent both variants. The easiest approach 
> here is probably to introduce the ttinfo structure, and make the current 
> library working with that. 
> 
> variant 1): has a map of transition points, returns a (pointer to a) ttinfo 
> structure. May hold more than 2 different ttinfo structures.
> 
> variant 2): always has 2 ttinfo structures (std/dst). Uses 
> dst-calculations/functions to lookup the transitions point, returns the right 
> (pointer to a) ttinfo structure. 
> 
> What do you think?

At first blush, I'd like to make as few changes to the abstract timezone as 
possible and would prefer to simply add a new subclass, but I'll keep an open 
mind as we work thru the details.

Jeff