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?
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.
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?
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.
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.)