RE: [boost] Date/Time formal review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-17 10:57:01

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

No, the touchpoint was 'universal' part.  I once thought, but changed my mind about the idea of
forcing all conversions in terms of one and only one system.  GPS and TAI, for example, might want
to depend on different reference points for conversion than say 'local time'.  That said, I fully
expect that UTC, which is the basis for most civil time keeping today, would be either the basis of
a standard point of conversion for time systems.  It just might not be the only one.

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

Well I'm certainly open to suggestion, but my study of the problem leads me to think it isn't that
easy for some of the reasons I have expressed.  There are implementation issues with resolution and
range matching of different systems as well as more subtle issues with the accuracy of each time
system implementation.  So at a minimum I think you would need policies for these issues.

Just as another example, a counted representation (something like time_t) of UTC projected into the
future more than 6 months runs the risk of being off by one or more seconds since a leap second
might be declared before that point in time.  So if you convert your future UTC time to TAI and are
expecting accuracy of second level or below you might be suprised when the answer is incorrect.  Of
course it was correct when you calculated it, but not when it occurs.  And of course if you convert
at after the leap second you will get a different answer.  So which is correct?

So my preference here is to be conservative and not offer a capability I can't see how to build
correctly.  Individual conversions two systems can be analyzed, explained, documented, and optimized
as users need them.  And if someone else out there can propose a solution that covers the bases then
your template is easy to add.

Jeff