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 representation. 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] 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 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions