In 2020, the Earth slightly accelerated its spin.
For the first time in history, we need to add a *negative* leap second in our datetime systems.
...
Which means all the datetime libs need an update. I hope they anticipated this.

The point of anticipating that would be not to need an update in the first place because it should be part of the initial design already.

All that work for just one second

Not a single datetime library accounts for leap seconds. If they did, then today's timestamp would be 1610928027 instead of 1610928000.

Uhh... does nobody know how datetime libs work? There is a single, authoritative database of time adjustment data for all of human history. If OP is correct then this is just another line in some data file.

The libraries that use this data file literally have to do nothing, lol.

It's not the end of the world.

@hitko Of course some do, it's required to format and parse date/time strings (non-UTC of course). For the algebraic bits, of course not.

@junon Unix timestamps by definition don't account for leap seconds, and neither does any library or programming language which uses seconds (or milliseconds) since epoch to store time. That covers about 99.9% of all programs and libraries ever written, with the exception of a few database engines and operating systems (but not programs running on those systems).

Try parsing "2016-12-31T23:59:60.000Z", and you'll see that almost every single piece of software either rejects it altogether, or converts it to "2017-01-01T00:00:00.000Z".

@hitko I didn't say Unix timestamps account for Timezones or drift. Of course they don't. I'm talking about date/time libraries, such as Moment.

Leap seconds are a fundamentally stupid idea in this day and age. We have very little need for things to tie in with astronomical time to the second, but a very great need to keep multiple clocks accurately and predictably synced across the globe, and likewise to make accurate, comparable measures of differences in time. Leap seconds mess all that up - it's one thing to deal with timezones, it's another to not know how many seconds you should count twice a year.

Leap minutes or hours would be a much better proposition. Wouldn't need to update them for hundreds of years at least, possibly thousands, so any could be planned and published something like a decade in advance (if another calendar hasn't taken over by then, which is likely.)

@junon For fuck's sake, just try it: http://jsfiddle.net/087m4vjw/1/

Does Moment understand a leap second in that date? No it fucking doesn't, because behind all that shiny façade it still uses Unix timestamp, and when you try to format that date, it has no fucking clue there's been a leap second on 31. December 2016. Yes I fucking know how date parsers and formatters work, but your sorry ass clearly has no fucking clue how those things work behind the scenes and you're trying to prove libraries treat leap seconds the same way they treat daylight savings time.

@AlmondSauce On the contrary, in this day and age it's trivial to keep millions of clocks synchronised across the globe because we have plenty of accurate time servers, as well as radio networks which broadcast accurate time, so we can totally afford to keep our time as close to astronomical time as possible.

I'm sure reducing that leap to another time unit would solve a lot of problems with keeping accurate time, but on the other hand it would mean mistakes in places where accurate time is really critical would be much greater, e.g. imagine the damage if, say, someone at NASA calculated trajectory in astronomical time, and the person in charge executed the action 20 seconds late / early.

@hitko I don't see why you keep bringing up Unix timestamps because clearly you have no idea what I'm trying to point out.

That code that would otherwise account for shit like this doesn't need to change if they're using the time change database.

Look at moment/moment-timezone. It uses the IANA time database. You are the one out of your depth here, friend.

@junon Fucking open my link, bitch. There's 3 lines of code, and they prove Moment doesn't do what you say it does, because leap seconds have nothing to do with timezones.

@hitko imagine being angry and calling someone a bitch over.... timezones

@junon No, I'm angry because you keep saying something over and over, instead of stopping and checking what's going on, despite people giving you everything necessary to do so.

Also time zones have nothing to do with leap second, and everything you've said so far applies to time zones and daylight savings time, not to leap seconds.

@hitko You're arguing for something completely different than I am. lol. You're the one not realizing that.

@hitko It's not just as simple as keeping a clock in sync, it's about how legacy software & systems behave (and heck, even more modern systems sometimes) when the change immediately hits - this can wreak havoc, causing anything from inaccurate results to negative numbers where there shouldn't be. Plus, some time libraries will deal with it and others will ignore it entirely, leading to inconsistencies across systems. Given that it's also usually on year rollover which can already be an edge case, it's not to be sniffed at - leap second bugs are *everywhere*.

In the past decade alone leap second bugs have taken down airline booking systems, Twitter, Amazon, Netflix, Cloudflare DNS, and many others. Heck, the stock exchange simply closed down for over an *hour* in 2015 just because the effort to work out all the possible issues was way too much.

Besides, even if NASA used the current leap second implementation they'd be screwed. Launch windows need *way* more accuracy than that.

@junon Yeah, I'm talking about datetime libraries accounting for leap seconds, which is the whole point of this thread. You're talking about time zones and how datetime libraries parse & format date at daylight savings change, and for some reason you're trying to prove that the two are the same.

@AlmondSauce Well Windows and all POSIX systems ignore leap seconds by default, and a system call to get time will return time without a leap second unless caller explicitly announces support for leap seconds. That makes behaviour predictable in most high-level software written after 1972, and it also means whoever encounters leap seconds on those systems should already know how to handle them.

The better question imo is how many developers on custom low-level software looked into it while implementing their solutions. For example, the Cloudflare outage comes down to how Go runtime tried to combine clock and time into a single functionality.

@hitko idk why you're dying on this hill. IANA manages leap second registries. Note the "tzdb" in the URL. That stands for "timezone database", which is used by many date libs.

https://data.iana.org/time-zones/...

Some date time libraries 100% use this data. Lol. If you're using a library that doesn't, fine. But any respectable date time library would use these registries to adjust localized dates and times.

Again, why are you dying on this hill?

@junon Quote:

# 5. If your system keeps time as the number of seconds since
# some epoch (e.g., NTP timestamps), then the algorithm for
# assigning a UTC time stamp to an event that happens during a positive
# leap second is not well defined. The official name of that leap
# second is 23:59:60, but there is no way of representing that time
# in these systems.

This covers all Windows and POSIX operating systems, and all software which relies on these operating system to provide time, for example every single FORTRAN or C program which uses time() calls, and every other programming language derived from them, a.k.a. all software in use today. And since they don't have a way to store or represent leap seconds, datetime libraries for them don't handle leap seconds either. Or do you have some magical way to handle something without representing it in the computer memory?