Converting TAI to/from UTC

Converting TAI to/from UTC

Post by William Thomps » Wed, 15 Sep 1993 08:18:53

Please forgive me if this is somewhat off the normal subjects for the
newsgroups that I am posting this to, but these are the closest matches that I
could find.

I just wrote some IDL software for converting between TAI and UTC time formats,
taking into account the "leap second" differences between them.  I thought that
it would be a good idea to check my results against those produced by other,
similar software.

If anyone does have such software, I would be grateful if the following example
(picked at random) could be confirmed/disproved.

        UTC:    1984-05-13 12:34:56
        TAI:    831,990,918 seconds since 1958-01-01 00:00:00

Thank you for your trouble,

Bill Thompson


1. TAI, UTC and POSIX-time

Thanks to the many people who have emailed and posted comments that
helped me get this clear (I hope):

International Atomic Time (TAI) counts standard seconds since a
well-defined epoch (in 1972) and names them with successive integers,
0, 1, 2, 3, etc.; there are no minutes, days, months or years in TAI.
A sufficiently stable oscillator can keep TAI time indefinitely without
outside involvement.

Univeral Co-ordinated Time (UTC) names the same seconds in the
conventional YYYY-MM-DD HH:MM:SS manner and it has the occasional hiccup
in numbering (23:59:60) that we call positive leap-seconds.  It isn't
meaningful to talk of ``UTC seconds'' in contrast to ``TAI seconds''
since there is a perfect 1:1 correspondence between seconds in both
systems; the only difference is how they are labelled.  To map between
historic TAI and UTC requires the use of a table of leap-seconds; this table is
being lengthened continually by the International Earth Rotation Service).

POSIX-time, or ``seconds since the epoch'' as they define it, is TAI
minus the number of complete positive leap-seconds in UTC up to that point
(plus the number of negative leap-seconds, but there haven't been any).
Unfortunately, this means that some seconds (the positive leap-seconds)
can't be given unique POSIX-time labels; such a second gets the same
label as its immediate successor.

For example:
        TAI     598 599 600 601 602
        UTC     :58 :59 :60 :00 :01
        POSIX   598 599 600 600 601

What we are having trouble with isn't really UTC at all---UTC ticks in
synchronisation with TAI quite happily---but with POSIX-time.  POSIX-time
is what you get if you convert UTC to an integer using the POSIX function:
        tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
            (tm_year-70)*31536000 + ((tm_year-69)/4)*86400
which leaves out all leap-seconds (and the leap day in the year 2100).

NTP currently distributes POSIX-time together with a leap-second warning
flag.  This is better than POSIX-time alone, since it is possible to
keep the warning flag and use it to disambiguate the POSIX-times around
leap seconds.  But what would be even better would be for NTP also to
convey the number of leap-seconds since the epoch; that value could
then be added to POSIX-time to get TAI.  What would be equivalent, but
philosophically best of all, would be for NTP to transmit TAI together
with the number of leap-seconds.

I am proposing that by one means or another, NTP is augmented so that
it provides enough information to enable an NTP client to report current
TAI, UTC and POSIX-times.

Robin O'Leary.

2. DHCP Trouble

3. TAI or UTC?

4. Applying Security Policies

5. cisco gk + tai wan fxs endpoint registration

6. Help!! NE2100 PCI Card

7. Thundercom ISDN 128K, TAi-05

8. Win2K Pro Remembering Passwords????

9. announce (pre-release): nanokernel #4 (TAI support)

10. announce: Linux nanokernel patch for TAI support

11. TAI with Xntpd?

12. TDT vs TDB vs TAI vs UT1