[ntp:questions] Leap second to be introduced in June
terje.mathisen at tmsw.no
Mon Jan 26 12:03:48 UTC 2015
Jochen Bern wrote:
> 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
One of the good points about Google's smear is the fact that they use a
half cosine to distribute the offset, which means that they have a time
function which is both continuous and monotonic, as well as having an
infinite number of defined derivatives, i.e. it is maximally smooth.
The _huge_ problem with their approach is that they have to make d***
sure there will never be any time leaks between their internal smeared
timebase and any external UTC/TAI clocks as long as the adjustment is
>> 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.
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
More information about the questions