Re: [boost] [date_time] Time zone improvements

Subject: Re: [boost] [date_time] Time zone improvements
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2008-11-21 07:26:06

Jeff Garland wrote:

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

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

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?

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

Cheers,

Rutger