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