RE: [boost] Date/Time formal review

From: Joachim Achtzehnter (joachim_at_[hidden])
Date: 2002-04-17 00:02:08

Jeff Garland wrote:
>
> So at some point when additional calendars are built with GDTL it might
> be useful to provide a single point of reference that multiple calendars
> could use as a conversion point.

To be honest, I think additional calendars such as a Mayan calendar, that
may or may not be added in the future, are not as relevant to the vast
majority of users. What I regard as more important is to support a few
widely used calendar/time systems well.

In this regard, it is probably useful to take note what facilities the C
library chose to provide: UTC and UTC-based local time representations.
These will likely be sufficient for the vast majority of applications.

In terms of supporting these well, I would expect convenient ways to
convert between UTC and local (ideally for multiple timezones). I would
expect convenient support for time computations, mostly related to
reasoning about duration between time points, and manipulations like "same
time in two days". These computations must work correctly for local time.
A "local" representation that only works for timezones that don't use DST
would have been useless for nearly all systems I've ever worked on.

Next in importance (in my personal, biased view) might be more
"scientific" representations such as Julian and MJD, possibly even taking
into account finer distinctons such as UTC, Atomic Time, etc., to keep
astronomers happy.

For the kind of applications I've been involved in, a separation between
date and time makes little sense. With this in mind, conversions between
all the above make perfect sense.

I think a design goal like "no dependency between different modules" is
nice in general, but in terms of date/time I believe it is more important
to provide what users will need. There won't be hundreds of different
date/time systems anyway.

How to manage conversions with an eye towards extensibility? Well, I do
think what was suggested by others, namely to designate a sensible
"standard" interchange format, such as a UTC-based epoch time or MJD (as a
double), makes perfect sense.

Joachim

-- 
work:     joachima_at_[hidden]  (http://www.netacquire.com)
private:  joachim_at_[hidden]         (http://www.kraut.ca)