Re: [boost] Date/Time formal review

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-04-17 09:31:17

----- Original Message -----
From: "Jeff Garland" <jeff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, April 16, 2002 7:15 PM
Subject: RE: [boost] Date/Time formal review

>
>
> Beman Dawes wrote:
> >When does conversion matter?  One case is when a user of one time system
> >needs to pass a time to a library which happens to use another time
system.
>
> Yes.  And the problem applies to both date and time systems.  For example,
suppose we built a Mayan
> Date system.  The specification of a day in the Mayan calendar is very
different from the Gregorian
> (can use 'the long count' which is broken down into a tuple of 6
elements - something like:
> 12.15.11.15.6).  In this case the 'resolution' in compatible so conversion
between the two systems
> makes sense.  So, the way the conversion done is that a point in time  is
set as the 'point of
> reference' using a basic counted system (eg: like a time_t count).  Each
date system needs to
> provide a functions that can convert any point to the point of reference
and back.

So, Jeff, I don't understand something here then.  I have to admit that the
arcane lore of time systems is at least a little foreign to me (I've tried
to do the research on this subject several times in the past since I've
rolled my own date/time libraries, but there's just too many strange
gotchas).  So, maybe my confusion lies in not understanding the subject
matter well enough.  But your two posts on this seem contradictory.

In the first post you say that "I also once believed this, but I have been
convinced that no such 'universal representation' exists."  Now you describe
precisely the system I had envisioned.  The only thing you mention in the
first post that might remove this contradiction is a reference to the
resolution of differing systems.  But so long as the "universal
representation" can handle the resolution (which should be mostly possible
if the universal representation is a struct that holds the time components:
year, month, day, hour, minute, second, millisecond, nanosecond all as
durations since a sentinal), then the only issue is with loss of precision
and rounding issues.  But neither of these should be compelling enough
reasons to not support the conversion.  It's only necessary that each time
system document any problems in these areas, and then it's up to the
programmer to get things right, much like casting from a long to a short.

So, am I just missing something here?

> >But what happens when in fact, at least for some values, the epoch and
> >resolutions are close enough that conversion is possible.  Could you give
> >an example of how to call a library function requiring a certain time
> >system argument, when your program has the value stored in a different
time
> >system?
>
> Sure, there are multiple ways this could be approached.  I'm going to
stick with the date example,
> but the same thing can be done with time.  One simple way is that the date
system could provide this
> functionality directly as a part of the date class.  For example lets
suppose we don't actually have
> a full date/time system for modified julian day.  We could have a simple
convenience function on
> date that would provide it:
>
> using namespace gregorian;
> date d(2000,Jan,1);
> long modified_julian_day = d.to_modified_julian_day();
>
> However, in the long run we would probably want free functions between
full systems like:
>
> gregorian::date gd(2002,1,1);
> mayan::date md = to_mayan(gd);
>
> The tricky part is that we don't want these date library to become
codependent .  That is I envision
> the Mayan system would go in boost/gdtl/mayan and I shouldn't need the
gregorian system to use the
> mayan system, and vice versa.  The only time I would need both is in doing
conversion between
> them...

That's where the template solution I mentioned comes into play.

template <typename To, typename From>
To convert(const From& from)
{
   return To(from.to_universal());
}
gregorian::date gd(2002,1,1);
mayan::date md = convert<mayan::date>(gd);

This template can live in the gdtl namespace and removes all dependencies on
other systems.  Your proposed solution of letting each system provide it's
own conversions on the other hand requires tighter coupling and
dependencies.  That's why I think it's essential that GDTL provide a
"universal representation".

Bill Kempf