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

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

I've been using a set of classes for years that is accurate to the precision
of your double, which means it is exact from the Gregorian cutoff of October
15, 1582 until February 11, 1,464,999. It has a little error for dates
before the 1582 cutoff. It also does business day calculations and every
other date computation I've ever heard of. Maybe we should compare notes?

----- Original Message -----
From: "mfdylan" <dylan_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, December 16, 2001 6:25 PM
Subject: [boost] Re: boost support for date/time handling?

> --- In boost_at_y..., "andreas_huber69" <andreas_at_h...> wrote:
> > Hello there
> >
> > I'm really unhappy with the date/time handling facilities currently
> > provided by the standard library.
>
> I assure you it's not just you :o)
>
> > class time:
> > - Represents an absolute point in time.
> > - The time of the day can be specified in hours, minutes, seconds
> and
> > nanoseconds.
> > - The date can be specified with the Gregorian calendar, support
> for
> > other calendars can easily be added without modifying the time
> class.
> > - Any point in time from about 4000BC until about 50000 years in
> the
> > future can be represented.
>
> 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?)
>
> 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.
> 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...)
>
> Dylan
>
>
>
> 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/
>
>
>