[LEAPSECS] operational time -- What's in a name?

[Steve Allen]

On Fri 2008-03-28T16:13:01 -0400, Greg Hennessy hath writ:

> Is it? I always thought it was a count of the number of seconds since

> the start of the unix epoch, not counting leap seconds.

>

> There having been 24 (I think) leap seconds since 1970, the unix

> epoch, if POSIX is UTC, then it can't be true that time_d % 86400 == 0

> is midnight.

>

> I've always considered time_t to be POSIX time, not UTC.


POSIX time_t counts mean solar seconds.  Admittedly, that's not what
the spec says, but that's what it does.  And that's what it has to do
if it expects the time_t to stay in phase with the calendar.

This is sortof like the time scale implicit in LORAN-C.

The LORAN-C networks have Times of Coincidence (TOCs) when an entire
chain is in phase, and those TOCs happen at intervals based on the
number of seconds elapsed since the TAI epoch, 1958-01-01.
Except...
Until 1972 the LORAN networks broadcast according to the time scale
which was approximating UT2 and which became called UTC, and after
1972 their time scale has tracked TAI.  So if you ask what time it is
according to LORAN-C you get a value 10 s different than TAI, because
the length of the LORAN-C second changed after it missed 10 TAI seconds.

And the inception of cesium at the LORAN-C transmitters matches rather
well with 1966 (the date at which the BIH last adjusted the length of
the UTC second) and also right around the time that the CCIR working
parties started seriously discussing leap seconds.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m