Re: [boost] Re: reminder about Date/Time formal review

From: Joachim Achtzehnter (joachim_at_[hidden])
Date: 2002-04-23 14:32:43

Michael Kenniston wrote:
>
> In general, when a timepoint is specified in an unpredictable system,
> it must be stored in that system - without conversion - in order to
> remain correct.

This is a good point. You're right that it is sometimes important to store
date/times in the representation in which they were entered. Whether or
not this is the case depends somewhat on the application's requirements,
however. Here are a couple examples:

1. You're recording events as they occur, say the runners of a marathon
cross the finish line, and you record the time when this happens. Even if
the user happens to enter dates in an unpredictable date/time system you
*do* want to convert to a predictable system using the conversion rules in
effect at the time the data was entered, and store in a predictable
format. The application's intent here is to associate "physical" time with
events. For such applications one should use the "best" available time
system to store the date/time.

2. You're representing a business rule, for example the fact that a system
will reject certain requests on a specific day in an unpredictable
date/time system. In this case you want to store the date/time when this
special day starts/ends in the unpredictable system.

> If we base the library on a model that accounts for the screwiness that
> the real world forces upon us, the structure of the library can stay
> cleaner.

Well, I still think we need both concepts: a date/time concept that is
intended to represent phycial time points, and various different labeling
systems, some of them perhaps screwy and with more or less ambiguous
conversions to the physical representation. To correctly deal with the
latter, I agree that a model that accounts for the screwiness is needed.

It is the application (or its requirements) that decides whether a given
date/time needs to be stored in one or the other representation.

> An excellent example.  Not only is the time system being used
> unpredictable, it's also irregular, providing yet another reason why we
> cannot base all time systems on physics.

Not sure what you mean by "based on physics" when you're talking about a
labeling system. We're probably talking past each other here.

> Joachim Achtzehnter wrote:
>
> > These concepts [duration of 1 year] make sense only in
> > the context of a calendar/time system. They are clearly not the same
> > concept as the physical duration defined above. In my view it would be
> > a mistake to pretend they are the same.
>
> There is a basic philosophical difference here.

Not sure whether "philosophical" is the right way to describe our
differences here. :-)

> The idea of creating a class which corresponds to the "real" physical
> time is quite attractive,

Not just attractive, there are application requirements that are best
modeled by using the concept of physical time. Other requirements are best
expressed using a particular labeling system. And finally, there are
applications that need both concepts, hence the importance of modeling
both, and not confusing them.

> When you speak of physical time, I'd guess you mean TAI (atomic clock)
> time, which is the best clock we have right now.  However, 100 years ago
> GMT was physical time, since the most accurate clock we had back then
> was the earth's rotation.  I expect 100 years from now the cesium atom
> will no longer be the gold standard for timekeeping (in fact NIST is
> already working on its replacement).

Yes, but this is no different from other physical metrics. Take length as
an example. Representing physical length in terms of meters makes perfect
sense in spite of the fact that the definition of the meter has changed
over time. Everybody will probably agree that the concept of physical
length is an important one. And here too, there may be certain
requirements where lengths sometimes must be represented in a screwy
labeling system, such as in units of the size of a certain human being.

> Therefore, I will argue that /all/ time systems are human artifacts,
> and the library will benefit if they are all treated as equally valid.
> Although this is a philosophical position, my argument is actually
> based on pragmatism - I simply couldn't get things to work out right
> when I tried to base everything on "physical" time.

You're right that the concept of phycial time is not sufficient for all
needs. There are requirements that need other concepts, which is why you
want support for these different labeling systems. But this doesn't imply
that the concept of physical time is *not* needed.

And yes, physicists may continue to evolve the definition of the second.
Computer systems similarly will implement the concept of physical time
more or less accurately, some may use GMT, others UTC, and some may even
use TAI. My main point is about the *concept* of physical time,
independent of its implementation.

Joachim

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