RE: [boost] Re: boost support for date/time handling?

From: Jeff Garland (jeff_at_[hidden])
Date: 2001-12-16 21:45:21

> class 'time' is not such a good name given that std::time is already
> reserved and it would be nice to have something that had a chance of
> making it into the standard sooner or later.  'date_time' is about
> the only thing I can think of (event_time? time_point?)

GDTL currently uses date_time for this name.

> One overriding problem: we do occasionally need to refer to points of
> time billions of years in the past and in the future, and likewise
> spans of time billions of years long (esp. in scientific
> programming), but it's only a fairly small period for which we need
> sub-second or even sub-day accuracy.  Two possibilities:
> a) templatize to allow accuracy/range tradeoffs, with
> necessary "lossy" conversions.

This is exactly what Generic Date-Time Library (GDTL) is meant to address.  You
pick the precision of the date_time representation system.  Basic template
classes are provided to handle the most common cases, but extensions for extreme
cases (eg: geologic_date) still work.  So for your case, the billion year
representation might not be able to even represent a single month or day --
perhaps the finest precision you want will be a single year -- or 100 years.  Or
you can use a large integer class to represent very long periods.

As for conversion, this is an open issue that has come up with another person in
private email.  I'm still thinking about the solutions here, but interestingly
it seems to me that a point_in_time for a date (day level precision) actually
represents a time_period in the higher precision system.  So you could do
something like take the period start, end, or midpoint when converting.

> b) determine some heuristic calculation that imbues certain time
> periods with particular accuracies
>
> The latter may be more convenient but hard to implement efficiently
> and in a sensible manner.  Less likely to be a real problem is the
> fact that it would eventually become out of date, whereas the
> templatized versions could allow picking a "point of reference", so
> in 200 years everyone can still use the same C++ standard library
> components ;o)  (I wonder if the thought of C++ code still existing
> in 200 years time seems as far-fetched to us as the thought of
> Fortran code still existing in 40 years did to those in the 1960s...)

GDTL allows overriding the epoch date by replacing the calendar component.  For
a standard gregorian calendar it might be possible to provide the epoch start as
a template parameter.  However, this is tricky in that date calculation systems
can be quite complex and to provide this along with conversions between calendar
systems (say Mayan to Gregorian) might not be possible.  Of course you might not
care about these alternative calendars.  Anyway, your main point is correct --
there is always a problem attempting to represent an infinite number line in a
finite number of bits...

Jeff