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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-04-23 14:35:17

----- Original Message -----
From: "Jeff Garland" <jeff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, April 23, 2002 1:38 PM
Subject: RE: [boost] Re: reminder about Date/Time formal review

> > 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.
>
> I believe the library is basically agnostic on this point currently.
> The main reason being that I don't claim to have the 'universal answer'.
> That doesn't mean that the library can't provide support
> going forward.  I believe the support to be trivial technically, but
> perhaps explosive politically.

There are a number of political issues, yes, but they exist regardless of
the ability to convert to/from a "universal representation".  I simply don't
believe that any political or mathematical problems with conversions are
compelling enough to not provide conversions, and conversions with out a
"universal representation" are simply too complex to be practical.

> Just to get back to ground for a moment, let's consider the case of
> calendar to calendar conversions specifically.  In this domain
> it would be my suggestion that moving forward we take the approach
> of Reingold and Dershowitz (call them R&D -- they wrote Calendrical
> Calculations).  The main reason for this is that they have done more
> work on this problem than any of us will in a lifetime (there's 2 of
> them for one thing :-).  They provide both algorithms, implementations
> (lisp & java), and test data for a broad array of calendars (coptic,
> islamic, mayan, chinese, and hindu to name a few).  This is a massive
> amount of work to try and replicate and I think it is generally
> foolhardy to attempt to recreate from scratch.

I don't follow what you mean by it being "foolhardy to attempt to recreate
from scratch".  Eventually I'd hope that GDTL provides all the functionality
provided by their algorithms, and in at least one sense of the term this
would be a "recreation from scratch".

> In the R&D approach they define a fixed date-time which corresponds to
> Gregorian Monday Jan 1 1 at noon.  Note that this is an extrapolation
> because there was no gregorian 1 1 since it wasn't invented until
> the sixteenth century.  So the approach they use to convert between
> disparate calendars is to write 2 functions:
>   fixed-from-x
>   x-from-fixed
> where x is the calendar.  With these two functions available for
> all calendars they can trivially convert between.  At this point,
> if calendar implementations provide these functions than the
> conversions can be pushed into a small template similar to what
> Bill suggested earlier.

This gives a lot more validity to what I've proposed, so I feel even more
strongly about this subject.

> So the question is, why does this work?  Well, it works because
> they implicitly assume that all calendars are based on 'earth
> centric' systems that correspond to a day being approximately
> 24 hours. R&D also control the implementation of the various
> calendars epochs and implementations so that the conversions
> work within the resolution of a 32 bit signed integer.  The
> calendars also have a large period of intersection -- essentially
> known human history. Even so, some of these conversions and
> calendars themselves are approximations.  If these assumptions
> are violated then the a different conversion mechanism might
> be needed.

So long as you can fix to points in various time systems as the same points
in time (which physics says should be possible, regardless of the politics),
you can provide algorithmic conversions to the "universal representation".
Mathematical artifacts and political issues will probably always make such
conversions imprecise, but that's simply a fact we have to live with in this
domain.

In any event, I'm not suggesting that all time systems have to convert
to/from the universal representation (at the moment I can conceive of a
system that wouldn't, but I'll concede the possibility).  I'm suggesting
that if possible, no matter the loss of accuracy, such a conversion should
be provided by a given time system.

> Unfortunately, the R&D approach does not really cover time systems.
> Certainly, a similar approach can be taken, but with time it is
> a trickier business.  For one thing, time systems can be all over
> the map on resolution.  This means that rounding/truncation policy
> needs to be considered.  I think that Bill Seymour has actually done
> some good work elucidating solutions to this issue.  That said, the
> variability of resolution means that two time systems might have
> dramatically different periods of representation.  If it is
> non-intersecting then conversion between would actually be an
> error.

Agreed, but the "universal representation" I'm proposing makes this less
likely to be a real issue for most time systems.  Instead of using a single
integer type to represent the time elapsed since the epoch, we'd use
multiple integral types for seconds, minutes, hours, days, etc.  If you need
smaller resolution we simply need to add milliseconds or nanoseconds.  If
you need larger resolution you add months, years, etc. (OK, I realize that
these aren't universal and it may be more precise to pick some other unit of
time that is precise here).  The addition of these will cause a need to
recompile everything, but it won't effect the interface or implementation of
any conversion routines.  Are there still issues?  Yes, but none that I'd
consider show stoppers.

> So as I said before, I prefer to be conservative about 'promising'
> specifics on this topic.  I believe there are practical solutions
> for many situations, and I believe we should let that evolution
> drive the solutions.  I don't believe anything in the library design
> impedes us from doing this.

I don't believe the design impedes us directly.  However, if we don't supply
the framework for supporting conversions to begin with we'll have people
providing direct conversion routines that simply won't scale, and this is
likely to alienate a significant number of users.

> One final point on this topic.  I see no reason why an individual
> time or date system should be 'restricted' from providing a direct
> conversion to another form.  And I'm generally inclined to add a
> few common ones directly.  For example, I could see extending the
> gregorian::date to have a method mjd() that would return the modified
> julian day.  A couple people have asked for this and it seems to me
> that this would improve the library so I'm inclined to provide it.
> Even if a 'specific' translation is written now, we can always
> convert it to reuse a more general scheme when that is agreed.

Not with out either polluting the namespace with duplicate methods for the
same functionality, or breaking existing code.  That's the root of the
reason why I think the universal representation approach is so important.

Bill Kempf