Re: [LEAPSECS] Mechanism to provide tai-utc.dat locally

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Tue, 26 Dec 2006 10:10:56 -0700 (MST)

In message: <20061226124029.GA3185_at_fysh.org>
            Zefram <zefram_at_fysh.org> writes:
: M. Warner Losh wrote:
: >Actually, the real answer is domain specific. There are many things
: >that don't really care (when do I need to make the next 20 house
: >payments, off by one second just doesn't matter at all since
: >transcations are batched on a daily basis a few days early).
:
: In that case you don't really want a TAI<->UTC conversion. You want
: an estimate of TAI<->UT1. Possibly you'd prefer an exact TAI<->UTC
: conversion but want to fall back on the planetary rotation estimate in
: the event that UTC isn't defined that far yet. The point is that you're
: asking a different question from the one that elicits "I don't know".

Well, if I compute an interval, using UTC times, then I can go back
several decates before the results start to be suspect. Going
forward, you can get up to almost 12 months error free at some times
of the year, and a little over 6 months error free (assuming
instantaneous distribution of circular C). But going out a year
you'll have at least one leap second opportunity. Going out 2 years
gives you 3, etc. This allows one to compute these long intervals
with only a small error. If I was to compute the number of seconds
between Jan 1, 2007 0:0:0 and Dec 31, 2008 23:59:50, the answer is
63071990 or 63071991 or 63071992. We have no way of knowing today how
many seconds are in that interval. We do know the answer is one of
the above. The error in not knowing is tiny, about a 6 parts in 10^7.
Large enough to matter for some things, not large enough to matter for
others.

There's been little work on having variable precision math of this
nature where the computation depends on the numbers involved and a set
of rules. The precision work for floating point does come closest,
because there has been a lot of effort paid to analyzing the different
sources of error, but there's little work that's been done on
computing the error in parallel to the actual computation, wrapping
that up into convenient data structures and allowing the programmer to
test the results for an acceptle error (or rather in this case
uncertainty).

In all the high precision time work I've done, the biggest, most
overriding problem has been: What's the leap second value for the
immediate past (< 1 day) or near future (< 1 month). Very little
matters outside of those parameters. UTC time is important for IRIG
(and other time codes), UI display, and atomic clock coorinated
measurements (more generally, any coordinated event), but little
else. Some time scale that one can use to pace the system, or to make
measurements against is needed, but TAI or TAI-like timescales will
fit the bill. The hard part is when you need to convert from one to
the other of the time scales and a realization of the limits to doing
that.

So the answer to my above question isn't "I don't know" but rather
63071991 +- 1 given the current leap second practices. It would take
a lot longer than a year to notice different behavior in rotations and
change the rules, but factoring that in would be a crap shoot at best.

The important thing to realize also in constructing time libraries is
that I can have a TAI time in the future that doesn't have a
corresponding UTC time now, but will have one the closer we get to it.
And vice versa. I can have a UTC time (say 23:59:50 Dec 31, 2008)
that has no TAI time associated with it yet, but will at some point in
the future before that time.

: >Writing a library that copes with both types of users can be
: >problematical at best...
:
: I think a different library is required. One is about atomic timekeeping,
: the other is about astronomy.

Well, one is about atomic timekeeping. The other is the civil
approximation of astronomy, since a purely astronomical answer depends
on exactly where you are, seasonal variations, etc.

Warner
Received on Tue Dec 26 2006 - 09:13:31 PST