[ntp:questions] Leap second to be introduced in June
Jochen Bern
Jochen.Bern at LINworks.de
Mon Jan 19 19:36:14 UTC 2015
On 01/19/2015 08:42 AM, William Unruh wrote:
> On 2015-01-19, Mike S <mikes at flatsurface.com> wrote:
>> On 1/18/2015 6:04 PM, William Unruh wrote:
>>
>>> UTC always has 31536000 seconds per year.
>>
>> You clearly don't understand how leap seconds work. You're embarrassing
>> yourself now. When there's a leap second, there are 31536001 SI seconds in
>> that year, that's the whole point. You may also be interested to learn
>> that a year with the similarly named leap day has 366 days, not the
>> usual 365.
>>
>>> Note UTC differs from TAI by an interger number of seconds, AND that
>>> integer changes with the leap second. Ie, it cannot be continuous if TAI
>>> is continuous.
>
> I quoted from the document you yourself pointed me at. TAI is
> continuous. UTC differes from TAI by and interger number of seconds, and
> that integer changes when a leap second occurs. If x is continous x-n
> where n changes at some time, is NOT continuous.
>
>>
>> Nonsense. When there's a leap second, there's a UTC second numbered
>> 23:59:60, ibid. Both UTC and TAI tick forward constantly, with each new
>> second uniquely enumerated.
>>
>>> TAI is monotonic and continuous. UTC thus cannot be.
You two *both* need to get your terminology (and its definitions) right.
First off, there's an actual timescale "UTC" (which includes leap
seconds, and represents them as the famous "23:59:60") and a timescale
that current unixoid (and other) computers use internally that is often
referred to as "UTC" (let me call it "time_t" from here on).
A year with a leap second has 31536001 seconds in UTC (and a great many
other timescales/-zones, as long as two consecutive turns of the year
have the same UTC offset). time_t claims that the year had 31536000
seconds (if you ask it in the first place).
The ultimate reason for this (historic) difference is that while the
definition of UTC includes leap seconds and even defines a notation for
it, it isn't *self-contained* because of leap seconds being decided on
and announced only half a year in advance.
Since there was (and is) no universal mechanism to distribute leap
second tables to computers, time_t was designed as a self-contained
approximation to UTC - at the price of it being neither monotonic nor
continuous (relative to physical time, and assuming the traditional
"step one second back" approach) over actual leaps.
I do not know whether there is an agreed notion of "turn of the year"
for TAI in the first place (as it deliberately does set itself apart
from astronomic events and, thus, "years"), so I can't really answer how
many seconds "a TAI year" has. Definition and representation of TAI
*suggest* a "year" of 31536000 seconds to me, but note that in this
case, the "turn of the year" is expressedly permitted to wander (all
over the calendar, if need be) as leap seconds happen and *are included*
in the TAI timescale.
Now for the *conversion functions*, where terms like "continuous" regain
their usual mathematical meaning in the first place.
Converting either TAI or UTC to time_t is, as mentioned above, neither
monotonic nor continuous.
Converting from time_t back to TAI or UTC is ambiguous and, thus, not
even a function.
Both statements above are true because time_t numbers the leap second
the exact same as one of the neighboring seconds.
Converting between TAI and UTC - imagine them as simple counters for the
moment, devoid of representational concepts like "hours" - is monotonic
and continuous, because both timescales include the leap second.
Actually it's a *linear* function.
Converting between *representations* of TAI and UTC, as in, HH:MM:SS,
suffers from the fact that UTC "special cases" the leap seconds (and we
*still* need the table of historic leap seconds to do it). Only *now* we
get the apparent(*) result that UTC = TAI - n seconds with an n changing
(increasing) in discrete steps over time.
Note that the above "conversion function" is, in fact, incomplete
because it fails to produce UTC's special value of "23:59:60" for the
leap second itself. A more correct definition would be
UTC(TAI) = ( TAI - n ) modulo 24h format
for times leading up to a specific leap second,
"23:59:60" plus the fractional seconds from TAI
during the leap second itself, and
( TAI - (n+1) ) modulo 24h format
for times following that leap second.
As you can see, the suspected one second "jump" of the conversion
between UTC and TAI has been filled with a unique value that is
supposedly sorted between the "23:59:59" and "00:00:00" values of UTC.
This "repairs" the alleged failure of the conversion functions to be
monotonic and and continuous.
Now let's return to the *incomplete* conversion functions and treat them
like they were the whole story - which they actually *are* if only we
consider time_t instead of UTC:
time_t(TAI) = ( TAI - n ) modulo 24h format
until some point TAI=t in time
( TAI - (n+1) ) modulo 24h format
starting from TAI=t
time_t(TAI) is a function *of TAI* that is neither monotonic nor
continuous in TAI=t.
TAI(time_t) is a function *of time_t* that is ambiguous (and thus,
again, not a function) in the interval [ time_t(t-1) , time_t(t) ].
The "of ..." part is important. Mathematics doesn't put the blame for
the function being "bad" on either time_t or TAI, it's a property of the
*function*, i.e., the very *conversion* from one to the other.
(*) Of course, the *real* basis of the "changing TAI-UTC offset" is that
the HH:MM:SS notation refers back to the last turn of the day, and
*that* got shifted out of its regular interval by the leap second for
UTC, but not for TAI.
[End of mathematician geek-out.]
Regards,
J. Bern
--
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
More information about the questions
mailing list