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.
The problem is not really with leap seconds themselves but that they are virtually universally implemented in computer systems as part of the "seconds-since-epoch time" as the lowest level interface to the clock (e.g. POSIX clock_gettime). This is apparently nice because then you can convert this to a calendar date without considering leap seconds (assuming the Gregorian calendar).
But for anything that actually needs accurate timekeeping (time keeping in natural terms not calendar time) this is a disaster because the time will jump by a full second, and if it jumped backward, this will also result in ambiguous times. So with leap seconds inserted into your clock, your clock may as well be worthless: it does not unambiguously define time, and you cannot subtract values to get durations.
Note that the current approach is not fully correct even when you care about calendar dates, because in case of a positive leap second, your clock will never show the :60 second tick but repeat :59 twice (due to ambiguity).
By the way, it is easy to convert a leap-second-uncorrected seconds-since-epoch value to a leap-second-corrected one (for compatibility with SW that assumes this). I think this will do it:
T_corrected = T - N_positive(T) + N_negative(T)
where N_positive is the number of positive leap seconds up to time T, and N_negative is the number of negative ones. (yes, positive ones are subtracted and negative are added - I hope I didn't mess that up)
Summary: leap seconds are not wrong per se, but they are implemented in a very stupid manner in common operating systems - the time values the OS gives allow neither correct conversion to calendar time nor calculation of relative times.
This is why clock_gettime() allows you to specify which clock to use. According to POSIX, CLOCK_MONOTONIC is not supposed to have any sudden jumps due to time adjustments or leap seconds, but can be adjusted for the gradual drift the clock experiences with respect to real world time. It seems perfect for your use case (if you don't want the skew adjustment there's also CLOCK_MONOTONIC_RAW, but since there is no skew adjustment it's only reasonably accurate for events that are close together).
CLOCK_MONOTONIC is good, but it's a local clock without a defined reference. So you can't use it on the network to synchronize different computers or otherwise communicate absolute timestamps. There should be a CLOCK_REALTIME_RAW or something that gives you the TAI time (UTC without correction for leap seconds).
That's great to know. I had no idea since it's not mentioned in the man page for clock_gettime (part of the "Linux Programmer's Manual"). Apparently the man pages are out of date.
Well having one aspect related to sun position (leap seconds) living in the raw seconds counter and all other aspects related to sun position (time offset, leap years, etc.) living in the human readable date formatting functions is unacceptable imho.
We either get rid of leap seconds in UTC time and treat leap seconds as a date formatting issue or we somehow get all OSes, libraries and applications to start using TAI time as their fundamental time counter instead (this is preferred but it's a lot of work, so yeah you're right about it being laziness).
Or i guess we can just continue living with the inconsistency of some sun position stuff being in the time counter and the rest in the date formatting functions (ick! there's a reason this is causing bugs all the time!).
I say it's preferable to eliminate leap seconds from UTC time and treat them as part of the calendar. It's not lazyness, it's just sane design. If everything was measured in calendar time, there is a lot of inefficiency involved for anything which does not need calendar time like calculating intervals.
> but it seems to me that the proposal to eliminate leap seconds smacks of laziness
Sure, and writing software with bugs and untested corner cases is also lazy. But we keep putting humans in charge of writing software...
> Keeping UTC within a second of UT1 has important real-world uses, including navigation and astronomy.
So put the work of handling a rare, irregularly occurring event on the few who care rather than the rest of humanity?
> redefining how we measure time to cope with bad code
This is basically what leap seconds are, a redefinition of time to fit a messy reality.
So again, why the assumption that we need a messy standard that all must fit to rather than a messy process of converting a simpler standard to solar ephemeris for the few who care?
Given that our industry has collectively shown it's unable to handle leap seconds well over decades of experience. Why not let the sectors that require a timescale closely tracking UT1 manage the complexity instead, and let the rest of us have a sensible time scale. I think you'll find that astronomers are already managing complex timescales, GPS itself doesn't have leap seconds (although it does broadcast the number of accumulated leap seconds between GPS time and UTC)
In GPS time, a second is a fixed length and days are a fixed number of seconds. By my reckoning, that means it does not have leap seconds. The UTC leap second is just another normal GPS second. The UTC leap seconds aren't disappeared as in unixtime.
Most applications of GPS time would prefer to display UTC time (since that matches most civilian uses), so the broadcast includes the offset so UTC time can be determined by the receiver.
> Keeping UTC within a second of UT1 has important real-world uses, including navigation and astronomy.
Really? I thought for both of those, you'd want to add some corrections anyway, like for astronomy, your longitude, because usually you aren't in the middle of your time zone anyway.
And if you need to add corrections anyway, why not quit adding leap seconds and handle them in those corrections?
You are not wrong, but in the real world, getting hold of an accurate representation of UT1 is very difficult, but knowing accurately UTC is very easy, and so in practice this is what is used for everyday civil purposes.
It it really so difficult? The difference between UTC and UT1 is broadcast by the different radio services, and you can also get it online (ftp://hpiers.obspm.fr/iers/bul/buld/bulletind.dat).
Also, apparently NIST makes UT1 available over NTP so you can just point your computer to it (https://www.nist.gov/pml/time-and-frequency-division/time-se...).
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.
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.
> 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.
The news is reporting a failure from 12:30am. It's possible that it might be due to the leap second, but given the 30 minute gap between the leap-second and the failure, I'd hesitate to ascribe causation just yet.
I haven't researched this problem deeply, so maybe someone can help me understand. Isn't any leap unit just a separately statable number that is used to translate between representations, very similar to time zones and DST?
Computer clocks ought to track actual elapsed time, but then systems should exchange that elapsed time and carry with it this metadata forming a context-appropriate representation, no?
Right now, converting a count of seconds (slightly fictitious UTC seconds, that is) since the epoch to a human-readable time is simple modular arithmetic. Any beginner in a programming language can do it.
If this conversion required knowing the number of leap seconds that have gone by, then simply displaying a human-readable time, or doing things at a fixed human-centric time of day like midnight UTC, would require a library almost as difficult to maintain and update as tzdata. In practice, some people wouldn't bother, and timestamps would gradually become ambiguous.
People on HN keep proposing tracking leap seconds the same way as time zones, and aren't thinking through the implications of having another tzdata-like layer that will display all your times wrong if you don't keep it updated. (Yes, GPS needs that layer. Most people do not program the GPS system.)
(also, just stop adding leap seconds, ffs, then this idea would work fine and nothing real would suffer)
Cool. That actually seems like a good idea, unlike the "leap seconds are just time zones, what's the problem" one. Now you're just left with the practical problem of changing the representation of timestamps.
(It's not even that the Unix timestamp representation was short-sighted. Unix was invented before leap seconds.)
I agree, we should design the best time system for the majority of people. None of this seems hard for any half decent bunch of programmers to deal with easily.
The problem is not with leap days. It's with leap seconds. The former are predictable, the latter are not. They are corrections introduced, when deviations are measured, to compensate changes in earth's rotation.
"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.
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.
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.
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.
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.
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.
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?
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.
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.
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/ for details.
And yes, I cleared the second change, but I in full disclosure it wasn't until 9 AM before I checked.
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.
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?
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).
> 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.
> They don't even seem to have a monitoring solution which can track what time each server is advertising.
Yes they do. http://www.pool.ntp.org/scores/ In fact the page linked to even specifically mentions removing bad servers from the pool in real time.
> I would switch to time.nist.gov if they had any servers in Europe.
You talk about "amateur hour" but are seemingly unaware that unless you are running an NTP server for a significant number of users yourself, you should not be using time.nist.gov. Given that you're apparently currently using the pool, I'm guessing you're not.
Regarding time.nist.gov, it's still there in the list of Windows 10 NTP servers that a user can select, albeit, by default it will only be polled once per week.
Assuming something (that you care about) works a certain way without verifying the assumption is amateur hour.
Why would NIST have servers in Europe? Almost all of the big national standards institutes have publicly available time servers, NPL for UK, INRIM for Italy, etc.
Of course it tracks what time each server is serving (and other meta data). That's how the system knows that many servers didn't advertise the leap second when they should have (at which time it's too late for the NTP Pool to do anything useful about it).
Reportedly several national time sources (not NIST) managed to not announce the leap second, too.
