
Leap second 2017 status - NelsonMinar
https://community.ntppool.org/t/leap-second-2017-status/59
======
LeoPanthera
I'm not a developer, but it seems to me that the proposal to eliminate leap
seconds smacks of laziness. Keeping UTC within a second of UT1 has important
real-world uses, including navigation and astronomy. The only problems it has
created are software ones, and redefining how we measure time to cope with bad
code seems like a ridiculous overreaction.

~~~
timthorn
The London Ambulance Service's Computer Aided Dispatch system failed around
midnight - the cause is not yet public, but it is conceivable that the leap
second of 2016 could have resulted in avoidable deaths.

Yes, due to a software problem, but with real consequences.

~~~
dx034
A system failure in the busiest night of the year (and apparently the busiest
night ever) can have many other reasons apart from a leap second. It occured
at 12.30am which is probably around the time when call volume started to
increase rapidly.

Do you have any source for the avoidable deaths? The night was very busy which
lead to delays for ambulance dispatch, but from everything I read, the control
room handled the situation well and there was little delay due to the system
failure.

~~~
timthorn
> Do you have any source for the avoidable deaths?

None whatsoever - I'm not saying that there were, nor that the failure was
actually linked to the leap second, and I tried to make clear in my comment
that the facts were unknown.

I was suggesting that avoidable deaths could be a plausible outcome of a CAD
system failing, and that the CAD failure could have plausibly been caused by
the leap second. This was in response to the comment arguing that the only
problems created were software, and I was trying to demonstrate that "only"
software bugs can have serious consequences.

~~~
timthorn
There's now an investigation into the clinical aspect, as at least one patient
died during the outage:
[http://www.bbc.co.uk/news/health-38535946](http://www.bbc.co.uk/news/health-38535946)

------
alpb
Some resources on how Google handles the leap seconds in their datacenters,
where this is no longer a problem:

\- [https://developers.google.com/time/](https://developers.google.com/time/)

\- [http://www.businessinsider.com/google-compute-engine-leap-
sm...](http://www.businessinsider.com/google-compute-engine-leap-smear-deals-
with-61-second-minutes-2015-6)

\- [https://cloudplatform.googleblog.com/2015/05/Got-a-
second-A-...](https://cloudplatform.googleblog.com/2015/05/Got-a-second-A-
leap-second-that-is-Be-ready-for-June-30th.html)

~~~
LeoPanthera
"Leap smearing" is a clever solution when dealing with software that cannot
tell time properly, but it does mean that your clocks will be up to half a
second out, on a day with a leap second. Useful perhaps if you run a
datacenter, but a poor solution if you actually care about accurate
timekeeping.

~~~
tedunangst
A large part of the problem is people who think they care, but really don't.

------
kbaker
Wow, did not know openntpd just ignores the leap second altogether.

[http://undeadly.org/cgi?action=article&sid=20150628132834](http://undeadly.org/cgi?action=article&sid=20150628132834)

~~~
NelsonMinar
Yeah that surprised me too. It's not a crazy solution for a client machine,
but no server running that should be providing time for others.

~~~
m-p-3
Anyone running openntpd should be kicked out of the pool at this point.

------
LeoPanthera
The number of servers in the pool is slowly falling. If you can spare a
server, why not join it?
[http://www.pool.ntp.org/zone/@](http://www.pool.ntp.org/zone/@)

------
alexkcd
The solution is actually quite simple. [1]

1\. Use TAI-UT1 (International Atomic Time, monotonic, no leap seconds, with
zero on 1958 Jan 1) for time keeping

2\. Define conversion functions that map TAI-UT1 to/from UTC/UT1/etc

Use TAI-UT1 when you want to:

\- synchronize the clocks of a network of computers

\- calculate time elapsed

Convert to UTC/UT1/etc when you want to:

\- Display a human readable date

\- You're writing navigation or astronomy software

Introducing leap seconds into UTC would then just mean updating the TAI<->UTC
mapping function. So all it would affect is how human-readable dates are
displayed & navigation/astronomy software is re-aligned to celestial body
positions.

[1]
[http://www.stjarnhimlen.se/comp/time.html](http://www.stjarnhimlen.se/comp/time.html)

~~~
tacostakohashi
What makes you think TAI<->UTC mapping functions are easier to update and
synchronize between systems than the time itself?

Quite a bit of experience with timezone databases would suggest it's actually
not that easy to update this kind of data globally and easily and short
notice.

~~~
alexkcd
Getting the mapping function wrong will only result in displaying a human
readable time wrong. Databases, and in fact all systems, should use TAI-UT1
internally and across computers. And only convert to something else when
displaying a human readable string.

~~~
ashearer
Then it would become impossible to store future timestamps in a database and
have a stable answer to the question, "on what day will this timestamp occur?"
Timestamps around midnight could flip from one day to another unpredictably
depending on what version of the leap second database the formatter has. And
that wouldn't just affect the leap second day, it would affect every day of
every year. That would cause problems for many fields where calendar dates
matter (legal and accounting, to name a couple). I expect we'd wind up
avoiding the problem by saving dates internally as formatted UTC strings, and
be back where we started.

~~~
alexkcd
That's true for software that cares about the location of celestial bodies. In
those cases use UTC by all means as event markers. That allows you to count
calendar days. However to calculate the duration between two dates down to the
second you will still first want to convert to TAI to get the correct answer.

------
labster
The astronomers responsible for leap seconds will be the first against the
wall when the revolution comes. Down with UTC, viva la TAI!

~~~
paulddraper
> astronomers responsible for leap seconds

Why stop at them? I'd take on that inconsiderate Sol next.

~~~
labster
Ah, a geocentrist. Welcome to HN, and enjoy the EM-drive threads!

------
baq
34 (or is it 35 now?) years since the first leap second, software still
broken.

~~~
amptorn
Software still botches leap _years_ , which have been a fact of life for
centuries. I think software generally isn't going to get any better.

------
AstroJetson
Yea, but next time is about 2020 so there is time to fix it.

~~~
jsjohnst
Say what? Leap seconds have been added 27 times in the past 45 years. What
would lead you to believe the earth's rotation will stop slowing down over the
next 33 years?

~~~
AstroJetson
Sorry, typo, was going for 2020

~~~
SEMW
OK, so what makes you think the next one won't be till 2020? Leap seconds
aren't like leap years, they're unpredictable, since the Earth's rotation
varies in response to geological events etc. The IERS announces them six
months in advance.

~~~
jsjohnst
Admittedly they've slowed down a lot since 2000 (happened at least 7x a decade
in 80s and 90s), but I agree, saying 2020 further shows the poster doesn't
understand how leap seconds work.

~~~
AstroJetson
Yikes!! I did a quick look at the periods between 1980 an now and guesstimated
that it would be 35 months to the next leap second (2020). As a Ham radio
person I get sun spots and solar winds which will make a difference on the
rotation.

But as an R programmer I went back and ran the numbers and it's looking like
2020. Happy to see that my Mark 1 Eyeball estimate was close. But I'm happy to
see what your numbers are.

With the advent of the Raspberry Pi support for time and the cheap GPS units,
I run my time locally. See
[https://blog.ntpsec.org/](https://blog.ntpsec.org/) for details.

And yes, I cleared the second change, but I in full disclosure it wasn't until
9 AM before I checked.

~~~
jsjohnst
Statistically modeling them using the prior dates of leap seconds alone isn't
a good method (if that's what you did, not claiming that it is). Knowledge of
the past leap seconds doesn't really tell you anything about when future ones
will be. A better way would be to model the difference between UTC and UT1 and
model the rate of change there. Probably the best would be to model the
earth's rotation rate and factor in the likelihood of the events that cause
variances. One major source of those events is earthquakes.

------
21
Wow, such amateur hour. I always thought that ntppool is run by competent
people, and that each server has at least a GPS time source. They don't even
seem to have a monitoring solution which can track what time each server is
advertising.

I would switch to time.nist.gov if they had any servers in Europe. Any other
good NTP EU source?

~~~
toast0
It's a free service, with volunteers providing the servers. There is
monitoring, but as far as I'm aware, common ntpds don't relookup the
configured servers while running, so you're going to be stuck to servers that
tested good when your server started.

The downside of nist.gov servers is that they're sometimes very overloaded
(and the one hosted in Washington state tends to have network path asymmetry,
resulting in a large time offset reported).

There are some lists of public servers linked from this page:
[http://support.ntp.org/bin/view/Servers/WebHome](http://support.ntp.org/bin/view/Servers/WebHome)

~~~
LeoPanthera
> and the one hosted in Washington state tends to have network path asymmetry,
> resulting in a large time offset reported

The NTP algorithm compensates for delays in network traffic. It will result in
a less accurate time, but it does not cause an offset in the resulting time.

[https://en.wikipedia.org/wiki/Network_Time_Protocol#Clock_sy...](https://en.wikipedia.org/wiki/Network_Time_Protocol#Clock_synchronization_algorithm)

~~~
toast0
Only if the delay is symmetric, as your link discusses. (asymmetric delay
isn't really measurable without good time synchronization of course)

