Daniel R. Tobias wrote:
>Formulas for UTC, as actually defined at the time, go back to 1961

But that involves rubber seconds, which is quite a big complication to add
to your TAI<->UTC conversion.  If you're going to handle pre-1972 times,
I think you really need to decide what you'll do prior to 1961 (when
UTC doesn't exist at all) and prior to 1955 (when there is no atomic
timescale).  POSIX punts on this: prior to 1972 time_t is implicitly
tied to an unspecified variety of UT.  (I wrote a bit about this aspect
of time_t in the Wikipedia article [[Unix time]].)

To be rigorously correct, applications should have distinct
representations for TAI dates, UTC dates, and UT dates.  TAI dates can't
legitimately exist that precede the first atomic timescale, and UTC dates
can't legitimately exist that precede either 1961 or 1972 (depending on
which concept of UTC is in use).  UT dates can exist for any time back to
four or five gigayears ago.  TAI and UT dates can exist arbitrarily far
in the future; future UTC dates can be considered, but some have only a
tentative existence.  Conversions can't be done very far into the future.

How things would work out in a system that pervasively used this
rigorously correct model I'm not sure.  We've already discussed
the aspects relating to present and future times.  For distant past
times it'd be necessary to explicitly process timestamps in UT form.
Possibly TT could also be used in some form, for interval calculations
in the pre-caesium age.

Whatever timescales are used for pre-1955 dates are, of course, also
available for present and future dates.  Perhaps, in this system,
many applications dealing with distant past dates would just use TT and
vague-UT for present and future dates as well.  This sounds sensiblish
to me: sub-second contemporary timestamps and also pre-caesium timestamps
in the same application seems like a specialised requirement.


Reply via email to