Boost logo

Boost :

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

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



Boost list run by bdawes at, gregod at, cpdaniel at, john at