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

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-23 13:38:39

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

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.

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.  

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.

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.

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.

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.

Jeff