On Fri, 22 Apr 2005 14:26:23 -0400, Beman Dawes wrote
Has anyone thought about boost.date_time? I believe this fills a lacking area of the standard as much as threads and filesystem.
There was a brief discussion of it at the LWG meeting, and there is interest. So the ball is in the developer's court. Jeff?
Short answer --> I'm working on it. Ridiculously Long answer --> It's taken much, much longer than I expected or wanted to get things to a place where I thought I could begin to make a coherent proposal to the committee. Since the first release I thought the core concepts time points, time durations, time periods, iterators, clocks, etc were the right ones. I also felt the 2 main implementations of these concepts (dates and times) where the most useful to the broadest range of applications. Experience has held up my expectations there. That said, there has been some really valuable evolution and conveniences added over the last few years as the library has been used in the real world. OTOH, since the first release I've felt the weakest elements of the library have been the handling of local times and i/o. It took a long time for me to see 'the light' on i/o. The first implementations of streaming facets were just too clunky and were too hard for users to use and extend. And the bottom line is that every project/person/standard has their own format for date-time i/o -- it's impossible to standardize what users want here. Luckily last summer Martin Andrian showed me the light with a partial implementation of a 'format string' based i/o facet (basically you can write: date_facet->format("%Y-%b-%d") to reset the format of a date in a stream). This approach solved a long standing issue on my standardization todo list --> how does i/o fit in with the existing format string concepts in the standard lib. Not to mention that it is almost infinately flexible in terms of how the various types can be streamed. This code will be the standard i/o facet in the 1.33 release. The local time issue turned out to be non-trivial. Early versions of the library had some under-powered attempts at solving this problem. 1.33 will contain an industrial strength solution. This includes an abstract timezone type and a couple implementations so that arbitrary timezones to be constructed from posix_strings or by using regional data via a variation of the tz generated from the 'timezone database' (a csv file the maps regions to zone rules). This, of course, includes all the gnarly daylight savings time rules. (At the end of the email I've included the code for my original challenge from 2002 to write a program that calculates the local departure / arrival times of a flight that crosses several timezones and 'flys thru' the daylight savings transition). So as 1.33 gets ready to ship I feel I'm now in a position to really work on drafting a proposal for the committee. I've written an initial outline and some text, but date-time is a non-trivial topic I have some tricky issues to explain. Best case scenario is the fall meeting -- worst case is...well I won't predict anymore ;-) Jeff //don't try this in JAVA -- it will hurt! //setup some timezones for creating and adjusting times typedef boost::shared_ptr<time_zone_base> zone_ptr; tz_database tz_db; tz_db.load_from_file("date_time_zonespec.csv"); zone_ptr nyc_tz = tz_db.time_zone_from_region("America/New_York"); zone_ptr phx_tz(new posix_time_zone("MST-07:00:00")); //local departure time in phoenix is 11 pm on april 2 2005 //ny changes to dst on apr 3 at 2 am -- luckily you don't need to //know that unless you want to be sure the answer below is correct local_date_time phx_departure(date(2005, Apr, 2), hours(23), phx_tz, local_date_time::NOT_DATE_TIME_ON_ERROR); time_duration flight_length = hours(4) + minutes(30); local_date_time phx_arrival = phx_departure + flight_length; local_date_time nyc_arrival = phx_arrival.local_time_in(nyc_tz); std::cout << "departure phx time: " << phx_departure << std::endl; std::cout << "arrival phx time: " << phx_arrival << std::endl; std::cout << "arrival nyc time: " << nyc_arrival << std::endl; Output: departure phx time: 2005-Apr-02 23:00:00 MST arrival phx time: 2005-Apr-03 03:30:00 MST arrival nyc time: 2005-Apr-03 06:30:00 EDT