Leap second 2017 status
community.ntppool.org
community.ntppool.org
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?
Which means that it does have leap seconds, it just doesn't use them internally.
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.
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.
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!).
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?
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?
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)
That way you still get the easy modular arithmetic, but an application that expects monotonic time still sees it (simply locally sum the two fields).
(It's not even that the Unix timestamp representation was short-sighted. Unix was invented before leap seconds.)
Yes, due to a software problem, but with real consequences.
https://quickview.cloudapps.cisco.com/quickview/bug/CSCvb017...
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.
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.
- https://developers.google.com/time/
- http://www.businessinsider.com/google-compute-engine-leap-sm...
- https://cloudplatform.googleblog.com/2015/05/Got-a-second-A-...
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.
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.
Why stop at them? I'd take on that inconsiderate Sol next.
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.
I would switch to time.nist.gov if they had any servers in Europe. Any other good NTP EU source?
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.
I never said that I'm a time expert.
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.
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
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...
Http://tf.nist.gov/tf-cgi/servers.cgi
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.
Reportedly several national time sources (not NIST) managed to not announce the leap second, too.