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