Re: [boost] Date/Time formal review

From: Joachim Achtzehnter (joachim_at_[hidden])
Date: 2002-04-17 12:24:36

Ross Smith wrote:
>
> The library suffers from a fundamental design flaw: it doesn't separate
> the concepts of "time" and "calendar". Time intervals and points in time
> are natural physical quantities that should be manipulated independently
> of the units we choose to measure them with. The approach taken by the
> "GDTL" (I don't think there's anything "generic" about it) would lead to
> an explosion of mutually incompatible sub-libraries for every calendar
> anybody wanted to use.
>
> A date/time library should have types representing "point in time" and
> "time interval"; these would be opaque, with operations for arithmetic
> on them but no intrinsic connection with any kind of human calendar.
> Then you can add "calendar" types that represent a broken down time
> represented in a specific calendar.

Couldn't have put it better myself. I've worked on quite a few
applications that needed date/time support and what you describe is pretty
much what I needed for those applications, with one addition:

> The calendar types would have no arithmetic properties themselves; they
> exist only to handle the conversion between the opaque time types and
> calendar-specific representations.

This I must slightly disagree with. While the "physical" aspects of time
you defined above are extremely important, many applications cannot avoid
dealing with the human and political aspects, and certain arithmetic
operations are needed here too. An example are rest time regulations for
airline personnel. Some of these are expressed in terms of the "physical"
aspects, mostly durations. But there are also rules that are expressed in
terms of calendar-specific artifacts. To deal with these one often needs
to do things like locate time points with special meaning, like the local
midnight preceding a given time point. This can always be implemented by
directly manipulationg the broken-down representation, but it would
certainly be more convenient if there was direct support for this kind of
calendar arithmetic.

> (Thinking about this a bit further ... there would be three orthogonal
> elements to a calendar type, probably supplied as template arguments:
> the basic calendar system (e.g. Gregorian vs Julian), the underlying
> astronomical time scale (e.g. UTC vs TAI; to put it another way, the
> definition of the relationship between seconds and days), and the time
> zone + DST rules.)

Agreed.

> Building Eurocentric assumptions into the language...

Not sure where you got that idea from? This doesn't look Eurocentric to
me. Almost all European countries use DST, which isn't well supported by
the proposed library. :-)

Joachim

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