TAI zone?

[Clive D.W. Feather]

Paul Koning said:
>> It is a mess.   Do remember that POSIX time is really neither UTC nor TAI.
>> That is, it acts like TAI, but the value is the same as it would be if it
>> were UTC.   POSIX manages this by making seconds be variable length objects,
>> so there's always exactly 31536000 of them in a year (31622400 in leap years).
> 
> Wow.  Are you sure of that?  If true, that is incredibly stupid.  It clearly isn't part of the charter of any such standard to redefine the metric system.
> 
> Also, even if it does pretend to define it that way, it isn't implemented that way in the real world.  I have never seen a system that uses nonstandard seconds, and I certainly will not tolerate such a system in any place where I have anything to do with its design.

Let me try an explain this. [I've just given a paper explaining this to
lawyers, so I should be able to do it to computer programmers.]

The SI second is defined in terms of vibrations of the caesium atom. Let's
imagine a counter that ticks exactly once every SI second. This counter was
started at the beginning of 1958 and has ticked steadily ever since.

Now let's feed this counter through the normal date-time decoding process:
    seconds = N % 60
    minutes = (N / 60) % 60
    hours = (N / 3600) % 24
    daynumber = N / 86400
    { year, month, day } = Gregorian_decode (daynumber)
This is the TAI clock. It ticks steadily and regularly, always with 60
seconds to the minute, 60 minutes to the hour, 24 hours to the day,
28/29/30/31 days to the month, 12 months to the year. Right now it's saying
2011-07-01 11:28:45. Note that TAI is a clock, not a count of seconds.

Now imagine a second clock. This also ticks once per second. Right now it's
34 seconds behind the TAI clock, so it is saying 2011-07-01 11:28:11.
This clock has 60 minutes to the hour, 24 hours to the day, 28/29/30/31 days
to the month, and 12 months to the year, but while it usually has 60
seconds to the minute, it sometimes has 59 or 61 - these minutes are always
the last minute of a month. So at the end of this year it could tick any of:

    2011-12-31 23:59:56    2011-12-31 23:59:56    2011-12-31 23:59:56
    2011-12-31 23:59:57    2011-12-31 23:59:57    2011-12-31 23:59:57
    2011-12-31 23:59:58    2011-12-31 23:59:58    2011-12-31 23:59:58
    2012-01-01 00:00:00    2011-12-31 23:59:59    2011-12-31 23:59:59
    2012-01-01 00:00:01    2012-01-01 00:00:00    2011-12-31 23:59:60
    2012-01-01 00:00:02    2012-01-01 00:00:01    2012-01-01 00:00:00
    2012-01-01 00:00:03    2012-01-01 00:00:02    2012-01-01 00:00:01
    2012-01-01 00:00:04    2012-01-01 00:00:03    2012-01-01 00:00:02

(and we don't yet know which of them it will be). This is the UTC clock.
Note that TAI-UTC is always an integer number of seconds.

How do we know whether a minute is 59, 60, or 61 seconds on the UTC clock?
That comes below.

Now, we live on a lump of rock and iron that spins. We're surrounded by
stars a long way away that provide a workable reference frame. Because we
go round the sun once a year, it's useful to construct a second reference
frame that spins, relative to the first, once a year. The angle between a
point on the earth and that second reference frame then goes through 360
degrees about every 86400 seconds.

If we make the "point" be somewhere on the prime meridian, count the whole
rotations and call them days, and convert the angle to a time in the normal
way (15 degrees = 1 hour, 15 minutes of arc = 1 minute of time, etc.) then
we get another clock. This is the UT clock (the difference between GMT, UT,
UT0, UT1, UT2, UT1R, and UT2R is not relevant for this discussion).

The value of the SI second was chosen so that the UT clock changes at about
one UT second per SI second. However, because the earth's rotation isn't
uniform the rate isn't exact or constant. This means that the value of
TAI-UTC isn't constant. Instead, at the moment, it is increasing at an
average of between 0.5 and 1 second per year.

And now we can explain UTC. UTC picks whether to have a minute that is
59, 60, or 61 seconds long by chosing the one that ensures that
|UTC-UT1| < 0.9s. The history of and predictions of the earth's rotation
are used to make the choice - so far we've never had a 59 second minute but
have had several 61 second minutes.

Now POSIX. The value of time_t is defined as ticking once per (SI) second,
keeping in sync with UTC, but ignoring leap seconds. This definitions is a
(slight) lie. What actually happens is that the counter increases once per
second most of the time, but at the end of a month:
- if the last minute has 60 seconds, it increases by 1 from 23:59:59 to
  00:00:00;
- if the last minute has 59 seconds, it increases by 2 from 23:59:58 to
  00:00:00 (a period of 1 second);
- if the last minute has 61 seconds, it increases by 1 from 23:59:59 to
  23:59:60, then does not change from 23:59:60 to 00:00:00 (so increasing
  by only 1 in 2 seconds).

Actual computer systems may follow this. Or they may alter the speed of
their internal clock to slew them back into sync with the value of time_t,
just as they do when they discover an error in their internal clock.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646