$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [date_time] Time zone improvements
From: Jeff Garland (azswdude_at_[hidden])
Date: 2008-10-21 12:25:29
On Mon, Oct 20, 2008 at 6:08 AM, Rutger ter Borg <rutger_at_[hidden]> wrote:
>
>
> Dear Boost.Date_Time developers,
>
Hi Rutger :-)
> Being a heavy user of Boost's Date_Time library, I think it is very useful.
> However, I think one area could use improvement: its time zone handling.
>
> I would like to bring the full Olson tz database [1] to Boost.Date_Time.
> This offers a very high-quality, and, on package-managed-UNIX-systems, a
> maintainance-free solution to a time zone database. I have written a modern
> C++ implementation for reading zic-compiled binary zoneinfo-files.
>
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?
I'm fine with incorporating a *nix only solution because what your
suggesting will be a nice solution for *nix platforms, but it will need to
be clear that it's not portable.
> At the moment, Boost.Date_Time is not able to represent time zones that
> have DST offsets and/or zone abbreviations depending on (or, changing over)
> time. I.e., if a country or locality changes its time zone definitions.
> E.g., a system that is in "Europe/Amsterdam" has changing DST offset and
> time zone
> abbreviation, which depend on time
>
> $ date -d "2008-10-10 20:00:00Z"
> Fri Oct 10 22:00:00 CEST 2008
> $ date -d "1930-10-10 20:00:00Z"
> Fri Oct 10 20:19:32 AMT 1930
>
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).
>
> I would like to propose changes that enables Boost.Date_Time to represent
> time zone definitions that change over time. The semantics will remain
> similar to the current version,
>
> boost::shared_ptr< time_zone > my_zone( "Europe/Amsterdam" );
> local_date_time some_time( pt, my_zone );
>
> some_time.utc_time(); // 2008-Oct-10 20:00:00
> some_time.local_time(); // 2008-Oct-10 22:00:00
> some_time.is_dst(); // true
> some_time.zone_abbrev(); // "CEST"
> some_time.dst_offset(); // 02:00:00
>
> in addition, the abstract Time Zone interface and supported accessors will
> have to undergo a change. Although the desired result may be achieved in
> multiple ways, I think the time zone base could support accessors like
> from_utc( ptime const& p) and from_local(...) methods, perhaps returning a
> (pointer to a) ttinfo tuple,
>
Ok.
>
> // UTC offset, is_dst, abbreviation
> typedef boost::tuple< time_duration_type, bool_type, string_type > ttinfo;
>
> and/or a special type in case the conversion is ambigious. When using the
> Olsen data base, this structure could be looked up through from_utc using
> std::lower_bound on a std::map or a ptr_map of transition points.
>
> I see a local_time_iterator is absent from the library, which I would like
> to add as well.
>
Yep.
>
> By way of this email I would like to ask whether there is interest the
> proposed improvement. If so, please let me know, so we can work on the
> details.
>
As the primary maintainer of Boost date-time I can say with certainty that
there is interest in this functionality -- it's long been on my todo list
and I haven't had time to get to it. You can email me privately and we can
discuss all the details of how to get your code incorporated.
Thx!
Jeff