[ntp:questions] Leap second to be introduced in June
michael.cook at sfr.fr
Wed Jan 21 10:39:10 UTC 2015
> 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
I couldn’t find a definition of a monotonous function. Does it exist? For me the term relates more to sound or the utterances of trolls.
> "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).)
The function can be non-linear. See below.
> 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.
This does not prevent the metric from being fully defined. The definition of UTC includes the definition of when a leap second will be inserted without limit to time.
1.1 The magnitude of DUT1 should not exceed 0.8 s.
1.2 The departure of UTC from UT1 should not exceed 0.9 s (see Note 1).
1.3 The deviation of (UTC plus DUT1) should not exceed 0.1 s.
There must be a field of maths which includes that notion of « fuzziness ».
Not knowing when one will occur appears to me to be irrelevant here. But then I am not a mathematician. As you point out later, I will agree that it could be « underspecified » , but I dont know what mathematical concept that refers to.
> 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.
Strictly speaking the conversion function of time is only continuous between xx:xx:00 and xx:xx:59.999… as we always go back to 00. That aside the fact that all watches that I know of do not contain a conversion function that adheres to the UTC recommendation just highlights sloppy engineering practices.
It is also conceivable to have a mechanical watch with 61 second divisions, a couple of buttons on the side to push for +/- leap seconds and cams which show/hide the relevant tick marks and speed the second hand from 58 through 0 accordingly at the rate of one SI second, thus retaining both continuous and monotonic properties. There is a certain non-linearality inherent in the mechanics (conversion function ) as the arc traversed by the second hand is not identical in all cases, but non-linearity dos not preclude continuity IHMO.
The UTC timescale can be seen in the same way. It is monotonic and continuous , with only incomplete realizations (conversion functions) tempting us to believe otherwise.
> 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?
Again, what you are highlighting is the inability or unwillingness of engineers to create sufficiently robust conversion functions.
When I say unwillingness, I mean that the UTC definition precedes the definition of POSIX by many years, but that POSIX did not see fit to take it in to account and the US government among many other governmental and private organisations required software contractors to adhere to POSIX standards. SO we have a whole lot of insufficient code out there prompting the miscreants to cry foul and demand that the rules be changed.
(off my soap box).
> 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
> questions mailing list
> questions at lists.ntp.org
More information about the questions