Re: [boost] Re: TR2 and C++0x heads up

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-04-22 22:49:22

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