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

From: Chuck Allison (cda_at_[hidden])
Date: 2001-12-16 23:02:20

I also call mine DateTime.

----- Original Message -----
From: "Jeff Garland" <jeff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, December 16, 2001 7:45 PM
Subject: RE: [boost] Re: boost support for date/time handling?

> > 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
>
>
> Info: http://www.boost.org  Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>