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

Jochen Bern Jochen.Bern at LINworks.de
Mon Jan 26 11:32:32 UTC 2015


Sorry for the delay, I'm *still* not back to my usual workplace ...

On 01/21/2015 11:39 AM, Mike Cook wrote:
>  I couldn’t find a definition of a monotonous function. Does it exist?

As David already suggested, I learnt my math in Germany - and switched
to CS before taking a shot at a PhD, which would have required me to
tear into actual current research, which would have been written in
English. So yes, "(streng) monoton" should have been translated as
"(strictly) monotonic", not "(strictly) monotonous".

>> (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.

Yes. In particular, implementing a leap second by decelerating your "all
minutes have 60 seconds" "clock" results in a conversion function that
is monotonic and continuous, but not linear. In the case of having it
run at half its normal speed for two seconds, it would qualify as
"piecewise linear" - and not have a defined derivative at the switchover
points.

>> 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 ».

Yes, but traditional functional analysis isn't it. :-} (Statistics or
Limitation Theory come to mind, but I don't have a specific concept on
the top of my mind.) The definition of "continuous" involves looking at
arbitrarily small intervals around the points in question. A "metric"
saying that the distance between two points in the future cannot be
guaranteed to ever get smaller than the uncertainty means that no such
intervals exist, and the definition of "continuous" falls flat on its face.

> Variant 2b.
> 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

I doubt we'll ever see such a *mechanic* watch being made. An *analog*
(with hands, and supposedly step motors and electronics driving them, or
"faking" hands with an LCD display or somesuch) or outright digital one,
sure.

Yes, the conversion to the timescale defined by that watch's second
hand's movement would be monotonic, continuous, piecewise linear,
invertible, etc.. It still needs additional input (the +/- buttons) to
remain true, and entirely separate data (historic list of leap seconds,
preferably with checkmarks that the buttons *were* pressed) to
accurately compute the time that passed between two readings, though.

> Again, what you are highlighting is the inability or unwillingness of
> engineers to create sufficiently robust conversion functions.

Well, if you want to put it that way, yes. Though unavailability of leap
second info within whatever system they're designing (say, a mechanic
wrist watch worn by an average human) is a pretty *solid* reason to
claim inability to do so.

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