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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-04-23 09:50:26

----- Original Message -----
From: "Michael Kenniston" <msk_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, April 22, 2002 1:31 PM
Subject: [boost] Re: reminder about Date/Time formal review

> 5) The ptime logic/arithmetic that Jeff has implemented corresponds
> to GMT, which although long officially deprecated is still what most
> computers actually implement.  We do need to add real UTC (among
> other things), but what is currently in GDTL is good place to start.

Strong agreement.

> Now on to some specific comments:
>
> Bill Kempf wrote:
>
> > I *strongly* feel that the gdtl
> > namespace "plumbing" *must* provide a mechanism for universal
> > representation.
>
> I disagree, and in fact claim that a "universal representation"
> is impossible to implement correctly.  I've implemented three
> date-and-time libraries myself, the latest two of which were
> grounded in a such a counted/physical/universal time system, and
> that experience led me to conclude that this approach is unworkable
> for a truly general library.  Jeff and I have discussed this, and
> I fully support his position that this is the wrong approach.

You contradict yourself, probably because you misunderstand what I want in a
"universal representation".  Let me explain.  Above you claim the following:

> 4) The distinction between /representation/ and /conversion/
> is important.  Even if a class cannot be implemented correctly
> using a counted representation, it can still be possible to
> provide a conversion to a counted system.  The catch is that
> the conversion will be approximate and unstable.  This is
> acceptable (well, actually I'd rather not accept it, but it's
> unavoidable) for a conversion, but not for a class's internal
> representation.

The "universal representation" is *NOT* supposed to be the internal
representation used by any given time system.  You are quite correct that
this is not going to work, and for reasons beyond the political difficulties
of time systems.  But that's not what I'm suggesting.  What I'm suggesting
is that there is a real need to translate from time system A to time system
B, and such conversions are *always* possible, even though the conversion
will be "approximate and unstable".  Jeff is suggesting that each time
system provide specific conversion functions to deal with this.  But with an
open system (i.e. the number of available time systems is not limited)
writing specific conversion functions is basically impossible.  What I'm
proposing is a "universal representation" that all systems must be able to
convert to and from.  This allows for conversion to/from any time system to
any other time system through an intermediary representation.  The only
issue lies in the loss of accuracy during each of the pair of conversions
required (and if a more accurate conversion can be made by skipping the
intermediate representation this would be possible with specializations).
In the quote above you've admitted that such conversions are acceptable, and
the reality is that such conversions are necessary in the real world.  The
library had better assist us here... otherwise it actually stands in our
way.

> Joachim Achtzehnter wrote:
>
> > Some calendar/time systems (those most
> > influenced by politicians) are so screwy that it is difficult to avoid
> > ambiguity in mappings, but that is another matter.
>
> Actually, I think this is the crux of the matter.  If we assume a clean
> predictable mapping from "physical" time to "civil" time, then we are
> condemning ourselves to a library riddled with exceptions.  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.

Violent agreement.  However, you're glossing over the need for conversions
*despite the loss of accuracy*.  The need is real, and the potential for
loss of accuracy is usually acceptable.  By your own (and Jeff's) admission,
such conversions are necessary and acceptable.  The difference is, I want a
universal representation to allow for generic conversions.  Anything less
renders the system unusable, IMHO.

> Joachim Achtzehnter wrote:
>
> > Strongly agree: Dealing with different time zones can be a very
> > frustrating experience. It is precisely applications that need to do
> this
> > that would most benefit from library support. At the very minimum I
> would
> > expect full support for one local timezone plus UTC, but multiple
> > timezones would be a real benefit.
>
> I too strongly agree.  I'm used to dealing with a dozen or so
> time zones (including DST and irregular special cases)
> simultaneously and consider that capability to be essential.
> I'm simply willing to wait for the next version to get it.
> Ditto for TAI, UTC, Julian, MJD, etc.

As am I.  But this brings the number of time systems up to, what 6?  The
version after that may have a dozen.  Can you imagine writing conversion
routines to/from all of these?  Don't you think such conversion routines,
even though not accurate, will still be a necessity?

Bill Kempf