[ntp:questions] Leap second to be introduced in June

Jochen Bern Jochen.Bern at LINworks.de
Tue Jan 20 23:14:31 UTC 2015

On 01/20/2015 10:58 AM, Martin Burnicki wrote:
> Wow, IMO this is *very* good summary of the problem, and explanation of
> the reasons for it.

Thanks, but after pondering the topic another night, I found my treatise
to still be faulty. :-} Let me try to amend:


The smaller point first, I suggested that imagining TAI and UTC in the
form of an integer counter would help understanding their properties.
That was me going overboard, I'm afraid.

You *can* try to imagine timescales that way, but in doing so, you'll
reduce almost all of them to an instrument keeping count of the physical
time ticking by, differing only by the offset from one to the other. How
these timescales treat leap seconds *is* a distinguishing feature, and
it is directly related to the bare counter's conversion into a date+time

As a corrolary, that means that - contradicting what I wrote before -
TAI *does* have a notion of days and years by means of having a
date+time representation, and since that one doesn't recognize leap
seconds, they're *all* 86400, 31536000 (non-leap year), and 31622400
(leap year) seconds long, regardless of leap seconds.


Back to mathematics. (You might want to run now. ;-)

The problem I have with people calling a timescale "monotonous" or
"continuous" is that those are mathematical terms, and they're defined
for *functions*.

(Quick terminology recap: A function takes inputs from one set (domain)
and assigns an output/result from another set (codomain) to them. In
order to define "continuous", both domain and codomain need to be
ordered and have a notion of "distance" or "difference" (metric).)

So, what *function* might people be thinking of when they assert those
properties to apply (or not) to timescales? The ultimate basis of
timekeeping is that physics gives us a concept of time, in particular, a
notion of measuring that time as it passes by, by means of a measurable
physical unit, the SI second. With that unit and equipment (and barring
relativistic effects for the moment), we can complement a set (of events
= measurements) with a metric (that tells us how much time passed
between any two measurements).

What we have got so far is for time what statements like "the pencil is
half a meter to the right of the ruler" are for space: Precise, but
local, in need of being put into relation with a global reference frame
to be useful. This reference frame needs to be defined, and *that* are
agreed-upon timescales like TAI or UTC. And in order to translate our
local measurement into such a timescale, we need a *conversion
function*. (Which we may later hide from sight by "syncing" a clock that
*knows* the timescale so that we can read the conversion's result from
it directly, but that's irrelevant here.)

So, what people mean by saying that a *timescale* is "monotonous" or
"continuous" is that the function converting the readings of a
measurement device (or, as the experts call it, "clock") into said
timescale has these properties. I don't remember much protest against
claims that TAI has those properties (but fails to stay well-synced to
celestial bodies). Now what about other timescales?

Let's take a step back from leap *seconds* and think about leap *days*
for a moment. TAI does take *those* into account, the result being that
some years have a length of 365 days and others 366 days. Why isn't it
an obstacle to labelling TAI as "continuous" that some years have a 29th
of February intervening between the 28th and the 1st of May, and the
others don't, apparently skipping an entire day?

The answer is that the "blame" for this behaviour is on the codomain,
not the conversion function. The set of date+time values and the metric
on it are *defined* in such a way that the distance between "28-Feb-2015
21:30:00" and "01-Mar-2015 22:30:00" is 25 hours, but the distance
between "28-Feb-2016 21:30:00" and "01-Mar-2016 22:30:00" is 49 hours.
The conversion function now maps 25 hours of clock ticks onto the first
timeframe but 49 hours onto the second - and comes out of the ordeal
smelling of roses, continuity, and even linearity.

Now let's apply that to the UTC timescale, which, unlike TAI, recognizes
leap seconds (and sets them apart). I shall define three different
versions of what the codomain for the SI->UTC conversion function
arguably *could* be, and obtain three different results what properties
the matching version of the function consequently has. And *that*, I
posit, is why people have so very different views on what "the
properties of the UTC timescale" are.

For the first version, let us assume that the codomain and its metric
have leap seconds incorporated in the same way TAI's codomain integrates
leap days. In other words, the metric "knows" that the distance between
"31-Mar-2015 23:59:00" and "01-Apr-2015 00:00:00" is 60 seconds but the
one between "30-Jun-2015 23:59:00" and "01-Jul-2015 00:00:00" is 61 seconds.

The first result would, of course, be that it's now the metric that
fails to be fully defined, as (most of) the future leap seconds are not
yet known. Second, however, as far as it *is* defined, the conversion
function would be just as monotonous, continuous, and linear as TAI is
with respect to leap days.

For the second variant, I'll take the opposite extreme (imagine me to be
a watchmaker hunched over the face of a mechanic wrist watch with its 60
tick marks for the seconds hand to rotate through) and claim that the
representation of "23:59:60" that UTC proposes for the leap seconds
plain doesn't exist.

What this means for the conversion function is that the claimed
representation for the leap second is invalid, and the function is
actually left undefined during that second. It is still monotonic
outside (23:59:59.99...,00:00:00), and continuous outside
[23:59:59.99...,00:00:00], and can be argued to be "monotonic" globally,
but it is *not* globally continuous anymore, because it fails to be at
the points in time where a leap second *is* inserted.

Third variant: Now I'll take the point of view of a software developer
who writes his code in such a way that minutes with a leap second slot
in them may have 59, 60, or 61 seconds, but may not assume that the
information which length has been pinpointed for the upcoming slot will
be *available* in time.

So that's for the set of values of the codomain for a leap-second-slot
minute (LSSM). What metric can our developer possibly define for it?
Chances are that he'll avoid the (worse) error of having one or even two
seconds which do not register *at all* with the metric, and decide that
LSSMs with their potentially 61 seconds should be assumed to be 61
seconds long (unless and until proven otherwise, which isn't going to
happen because sysadmins are lazy).

Which is the correct thing to do for LSSMs that actually *have* a leap
second inserted, so for those, the conversion function is again
monotonic and continuous. However, the conversion function now has to
*skip* a second for every LSSM that turns out *not* to have a positive
leap, which is still monotonic, but not continuous behavior anymore.

Wait a second, what was that? As far as continuity during LSSMs is
concerned, we now have a variant 2 and a variant 3 that are the *exact
opposite* of each other, in spite of the fact that we're still talking
about the same timescale, UTC! How's that possible?

Quite simple, actually: We've taken the uncertainty about the actual
length of LSSMs and shoved it from the codomain to the conversion
function and back in different ways, and whenever and wherever we
assigned it to the function, the function ceased to be well-behaved. Big
surprise. Whenever and wherever it is assigned to the codomain instead,
we're looking at a metric that is underspecified until the IERS bulletin
on the LSSM in question is out. The fact that leap seconds aren't nailed
down for all future has to be adressed *somewhere*, even in TAI, where
function *and* codomain are nailed down - but the offset to
sideric/civil time and its approximations isn't.

[Steps off soapbox and takes a swig from his Klein bottle]

								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