
Dear Boost.Date_Time developers, 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. 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 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, // 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. 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. Kind regards, Rutger ter Borg [1] Sources for Time Zone and Daylight Saving Time Data, http://www.twinsun.com/tz/tz-link.htm

Rutger ter Borg wrote:
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, [snip] 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.
Yes, there is interest. Timezone descriptions do actually change every now and then, only a couple days ago I saw an announcement of changes in the Brazilian and Argentinian DST rules. --> Mika Heiskanen

On Mon, Oct 20, 2008 at 6:08 AM, Rutger ter Borg <rutger@terborg.net> 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
participants (3)
-
Jeff Garland
-
Mika Heiskanen
-
Rutger ter Borg