RE: [boost] Date/Time formal review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-17 09:27:15

> 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.

I agree, but I used it as an example to point out that the domain of date-time systems is extremely
rich.

> 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.

Agreed.  The library provides more facilities than the current C library for exactly these purposes.
The only thing you don't have is a nicely bundled time class that hides these from the user.

> 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.

The library provides the foundation for all of these calculations as it is today.  I would be
interested in specific criticism of those mechanism.  I have an experimental local time system that
does exactly what you are saying.  However, I didn't include this in the initial submission due to
the additional time required to both polish and review.

> 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.

Yes agreed.

> 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.

Fair enough, I've seen the opposite.

> 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

I don't see a conflict between these goals.  The current time system implementation uses a gregorian
calendar because it is the most widely used and it was convenient to do so.  Other time systems
won't use a calendar except for conversions. I'm thinking of things like TAI and GPS.

> to provide what users will need. There won't be hundreds of different
> date/time systems anyway.

No, but possibly as many as a couple dozen.  Calendrical Calculations details 15 different calendar
systems.

> 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.

Where reasonable I have no problem with that.  But be careful, it isn't a 'format'.  It is picking a
reference time and rules for conversion between systems.  There are tricky issues like how to handle
time points that might be outside the range of the target system.  Maybe you don't want to allow
that, maybe you want to allow extending  the range of the system.  Both might be reasonable.  There
are also issues of accuracy.  For example if you projecting a 'local time' into the past and you
really need to get the exact answer you have to take into account the ever changing DST rules.  For
example, during World War 2 (and many other periods) the DST rules where different in the US than
they are now.  This makes calculation very difficult.

The current time system is in a sense the most basic and flexible because it makes no internal
adjustments.

Jeff