>remain at the current level of 27, which we believe will be enough for the next millennium.
I would have loved to read more justification about _why_ Meta thinks we no longer need the leap second beyond calling it a community push. They did a great job of complaining about how hard it is to solve from a technical perspective, and then explained how they solved it. Is the only problem really that Meta doesn't know how to test a negative leap second?
> This periodic adjustment mainly benefits scientists and astronomers as it allows them to observe celestial bodies using UTC for most purposes. If there were no UTC correction, then adjustments would have to be made to the legacy equipment and software that synchronize to UTC for astronomical observations.
> While the leap second might have been an acceptable solution in 1972, when it made both the scientific community and the telecom industry happy, these days UTC is equally bad for both digital applications and scientists, who often choose TAI or UT1 instead.
The claim is that the benefits accrue primarily to a community whose relative importance is minuscule compared to the broader software world in 2022. The tradeoff was made in 1972, when astronomers etc represented a vastly larger proportion of software.
Because time in the real world uses leap seconds. The time businesses open and close. The times reported in news articles. And so on. What facebook wants is for all of them to stop using leap seconds so facebook’s infrastructure is simpler
The article you linked seems to be arguing pretty strongly against leap hours. I'm not sure we could solve all those problems even in 3000 years. Can we compromise and use leap minutes? That way the problem is a bit more immediate, in 50 years we're sure to have solved it; or we'll all be dead and it will be on someone else!
Instead of leap hours we could just permanently abandon leap anything, and state that the offset between UTC and TAI is fixed at 27 seconds from now on, forever. Every few thousand years, when this new UTC has drifted enough from solar time on the prime meridian for people to start noticing and caring, countries can decide to simply change their offset from UTC, which will just be a normal update in the time zone database that doesn’t need to be coordinated with anyone else, i.e. something that already happens quite regularly.
This is all quite hypothetical as it’s hard to predict whether anything like our current technological civilization will exist thousands of years from now, but even if it does, a simple mechanism exists to avoid problems (just have each jurisdiction change their local time when they decide they want to).
I can’t see any downsides for literally anyone from this proposal, other than the insignificant downside to the British that they will lose the prestige of being the place that global standard time is based on.
It infuriates me that the BBC World Service insists on announcing the time as "<something> GMT", pronounced in a smug tone of voice. The GMT timescale no longer exists; nobody broadcasts it. What the announcers are broadcasting is the BBC's ignorance. I find it embarrassing and jingoistic.
They've also adopted an idiosyncratic way of pronouncing the time itself: "The time is Four, GMT". Everyone else says "Four O'clock", or "four hundred hours" or "four AM". The Beeb are almost completely immune to complaints; they've outsourced their complaints department, and the contractor's brief is to make sure no complaints reach programme makers.
Time may change forwards and backwards, because my computer clock may be fast or slow. The same logic to correct for leap seconds, can be used if my computer is 2 sec fast.
And your code had better handle it, and the os, libraries, it really is only hard ), if you have to support 1000s of novice devs.
And FWIW, every major company does have to support a thousand novice devs, every year, over and over, forever.
Honestly, this issue screams education problem. "Time is a mess" should be taught alongside buffer overflow attacks and networking theory (in fact, networking theory is a great place to teach "time is a mess," because you can roll it in alongside ideas like "simultaneous action is a lie" and "clocks are always wrong anyway").
Because they are lazy and are not aware of the prior work.
Already decades ago many have proposed to use only TAI internally in computers, instead of UTC, which is not a time.
UTC should have always been used only to compute the local times, together with the time zones, only for human interfaces.
There have been for decades libraries for using TAI instead of UTC, and even versions of Linux or *BSD kernels patched to do time keeping in TAI, not in UTC, eliminating all problems with the leap seconds.
Unfortunately the use of TAI has remained a niche, but that was the right solution.
Because they have to interact with the rest of the world, and billions of lines of computer software and hundreds of thousands of protocols have been written to use UTC instead of, say, using TAI and computing UTC on a presentation basis like timestamps are handled.
The thing is, similar reasoning can also be used to promote getting rid of leap years. Heck, maybe just switch to 12 months of 30 days while we are at it.
If you want to use real-world time, you have to make sure it stays in sync with the real world. Switching to something which is close-but-not-quite-correct will cause even more issues than we are currently having with leap seconds. Can't deal with that? Well, just use the Unix timestamp like the rest of us?
Yeah, if it wasn't for that pesky requirement to keep in sync with the wall clock, my life would be so so so much easier not having to deal with drop frame timecode. The video industry isn't exactly small, and nobody has just up and decided "meh, it's too hard, so we're going to push the everyone else to do what we want". We all put on our big boy&girl pants and do the work.
The video and music industry has been screwing a lot of our digital lives with mandatory encryption and anti hacking/reverse engineering requirements just to sustain some of their business models. The abstraction layer is different than this, but god the irony.
Of course, drop-frame timecode itself imperfectly compensates for the fractional framerate, and also as a result of the math not really working out there isn't a drop-frame standard for 23.976 fps at all, so sometimes the industry just throws up its hands and says "meh, it's too hard."
It's not that they don't have DF for 23.976 because it's hard, they don't because it wasn't needed. A 23.976 framerate was never broadcasted as it wasn't part of the NTSC standard. In fact, rarely did anyone actually edit at 23.976 unless it was going back to film. They cut the telecined film as 29.97 video with no regard to A-frames or any other methods that would enable the edit to cleanly go back to source frame rate. They so didn't care that some times the film cadence changes on every single edit. Why? Because nobody needed it nor could they possibly imagine the time of the internet and digital streaming that could do any frame rate to even bother wasting time trying to do it "right".
Well it _is_ in the standards now and you still see just non-drop timecode being used on it, with the resulting noticeable skew from wall time as the duration gets up there.
Again, it is not a broadcast standard, at least in the US. Pretty sure it's not in non-US markets either. Sure, it's a format that modern decoders and monitors can handle, but it's just not a format that people are concerned about it matching wall clock.
The issue is that all timekeeping is going to be an approximation of our messy Solar System. The only question is, "How accurate is accurate enough?"
Currently our calendar goes off by one day in 3236 years. If the history is calendars is indicative, in about 10,000 more years we may change our calendar. (Or, being multi-planetary by then, maybe we'll consider it a quaint relic of our origin.)
Our clocks predict astronomical time of day to less than a minute for a human lifetime. And both DST and timezones demonstrate that we're happy to live with the clock and Sun disagreeing by an hour or more.
My position is that both are currently good enough for the next couple of thousand years. And we can let our distant descendants sort it out when the time comes.
> (Or, being multi-planetary by then, maybe we'll consider it a quaint relic of our origin.)
It’s more likely that every planet will have its own calendar and you’d have to do the conversions and translations. That’s what scientists do with Mars time. Thanks to relativity, time at point A is not the same as time at point B, and whether they stay in sync for you depends on how you get from A to B.
The calendar point is possible. But the special relativity point, not so much.
While "now" can vary according to the time it takes to get from A to B, all observers can work out what "now is according to the reference frame of the distant stars". On a mere interplanetary scale, this idea is amazingly precise. We might not agree on how much time passed (this has already mattered for GPS satellites), but for all practical purposes "now" is perfectly meaningful.
Yeah, looks like it would work out fine. Since synchronous communication breaks down pretty quickly even on merely interplanetary levels, the remaining use for calendars and timekeeping is basically event planning. For that difference in reference points and interval duration is not that important, as long as you can compensate for that, making events happen at a time you expect in a place you expect. We're doing that fine already, communicating with our deep space probes.
I can see that, but I disagree that it's enough of an explanation. The blog specifically gives an example of the Earth's angular velocity changing with the melting of ice caps. They even threw in a cute animation of an ice skater to explain it. Last I checked, we're in the midsts of global climate change which is rapidly melting our ice and raising sea levels. I'm supposed to take Meta's word that we'll never need another leap second then? Why is that the case? Instinctually it makes sense to me to have a clock that follows the Earth's rotation. Why does Meta believe this is no longer the case? The only justification I saw was "it's hard" followed by their explanation of how they've solved it already. So what is the problem that's being solved by not counting leap seconds?
So, time is a human construct and Earth doesn't care how we measure it.
It's not that we'll never need another leap second; we could add ten, negative ten, or zero in the next 25 years and Earth won't care. Who will care are humans, who may get a bit annoyed when the sun starts setting in equatorial latitudes at 3PM.
Actual research astronomer here, and as a (radio) astronomer I would love to get rid of leap seconds. Assuming that UTC = UT1 (the time measure based on Earth rotation) is not accurate enough for most calculation such that you already need to use UT1 tables/forecasts and leap second tables in your ephemeris calculations so there isn't really much benefit in trying to keep UTC close to UT1. And the reality is that for us they actually make things worse: we stop data acquisition at the telescope over the leap second period because we timestamp our data in UTC dealing with the changing interval would be a pain.
There are some good arguments for keeping leap seconds, but I don't think research astronomy is really one (it might be more useful for amateurs), particularly on ~100 year timescales where you don't expect things to slip that much. I think this sentiment is shared by most of my peers, particularly those who actually have to implement data acquisition and analysis pipelines!
I can't imagine people who need accurate timekeeping (like scientists, astronomers and the telecom industry) preferring UTC over TAI. They do however prefer UTC over UT1. UTC was a reasonable compromise in the sense that it's almost TAI, but is close enough to UT1 that you can get all countries on board without much effort. Imagine getting the whole world on board to accept a mysterious device that counts electron transitions, without giving some kind of reassurance that it won't deviate in any relevant way from the timekeeping system they are used to.
You're probably right about the corporation, but some of their component organizations and assets may survive as long or longer, albeit after being resold, merged, acquired a few times. It could happen, you never know.
After all, there are still pieces of the original Bell organization and infrastructure around in active use, just with the names on the business cards and buildings changed. I don't think someone 50 years ago could have predicted which parts would still be around and which long gone.
Facebook will be able to test and handle a negative leap second better than most organizations in the world. Its everyone else they are worried about. If the rest of the internet breaks from a negative leap second, it doesn't really matter if facebook's servers all stay up.
I can't quite reconcile the FB attitude of "we only hire the best and brightest after making them demonstrate their technical prowess" vs "computers are a bit hard please can everyone change everything to make it easier?"
Why not just agitate for a move to French Revolutionary Decimal Time as well?
This is not a case of "computers are a bit hard", it's a system that we've imposed upon ourselves that has been repeatedly demonstrated to be unsafe. because of this, we've ended up with many (many) solutions baked into software that attempt to abstract away the sharp edges of this problem from individual engineers, which leads to inconsistent assumptions about what you need to consider when writing code.
even with the best and brightest engineers there is a non-trivial probability that someone will make an assumption that is invalid based on their understanding of what can happen (ex. leap seconds never go negative!) or the library their using (this ensures monotonic time!) that could lead to disastrous results. and especially at meta scale, that probability is no longer "will someone make this mistake in our code?" but is "how many times will people make this mistake in our code?", so systemic solutions that eliminate this as a class of problem an individual can create is something we should consider.
whether you like it or not, people are using facebook (and google, and amazon, and so on) as critical infrastructure.
there are also all the other companies out there who do not have the platform that meta has that can also hit the same issues. i'm sure some of them have products you wouldn't be so glib about.
>whether you like it or not, people are using facebook (and google, and amazon, and so on) as critical infrastructure.
Only facebook here is the one suggesting we should change things, so who is using facebook as critical infra and what is your definition of "critical" here.
Is UTC as a system inherently unsafe or does it just expose unwary programmers to bugs, the vast majority of which are somewhere between benign and inconvenient in impact?
If you want a system with no leap seconds use TAI. This is not rocket science. I implemented this in my first real job for a broker trader in 2009 who had exposure in Japan and Australia (leap seconds happen at 10/11am there).
If a 21 year old grad can move 200 terabytes of historical data 15 years ago what are the best and brightest at FB doing with their lives?
My exact first thought as well, which I will readily admit comes mostly from my bottomless contempt for the company and its employees. The thing that really needs to be left in the past is Facebook.
It's frustrating that programmers want to redefine civil time just because it is "hard". This article glosses over the real world problems that detaching from UTC will cause.
(You may want to scroll down to "Implementing the plan outlined at Torino".)
If we end leap seconds, it doesn't take long - only until 2028 - until "midnight" is sufficiently far from "the middle of the night" that you will have to consider the legal issues caused by events that happen just before or after 0000 hours.
By 2055, the "minute" displayed on a clock may be incorrect, which again may cause issues with legal timestamps.
And by 2083, sundials are measurably wrong.
All because programmers wanted to save some lines of code.
Astronomy very much relies on the leap seconds. If they ever get abolished it will create lots of headache for all observatories (and hobby astronomers as well), since the telescopes will point more and more incorrectly as UTC drifts away from UT1 (the leap seconds ensure UTC is always within 0.9s of UT1).
To explain a bit further: UT1 tracks the Earth's rotation relative to distant quasars and is thus directly the correct clock/reference to use for pointing telescopes.
However it doesn't advance at a nice and stable constant frequency, but something that slowly changes over time (and can shift by strong earthquakes) and thus we approximate it with UTC, which runs at a nice constant frequency, but needs occasional correction to match up with Earth's rotation.
Well, having worked on legacy systems it’s much easier to keep the existing protocol mostly unchanged than migrate the world to a different protocol. Even if the change is as “simple” as subtracting a constant integer everywhere. Just thinking about all the stored timestamps in all databases gives me a headache…
Because UTC already has no other purpose than to be what everybody is already using. The leap seconds in UTC benefit literally nobody. But being a standard is a purpose.
Changing to TAI means you are different from everybody else, and still have to fool with leap seconds to know what everybody else is using. Worst of all worlds.
(Except Google smearing, which is even worse than that.)
That's literally not true, since we astronomers do use UTC as it is intended (since within 0.9s of the correct time is good enough, but being many seconds off isn't anymore for many applications).
The argument that the legacy systems should maybe be updated is already being discussed elsewhere, so no need to rehash that.
Hardly. For actually observing with a telescope UT1 is the correct time scale to start the calculation from, since it's directly linked with Earth's rotation - with some complications that you have to calculate local sidereal time and so forth, but this only involves fixed constants; All TAI derived fixed-offset time scales are not linked with Earth's rotation and thus require constantly updated offsets. For most telescopes approximating it with UTC gives good enough results (pointing accuracy wise), so that's what many observatories do. And many smaller and older observatories operate quite a lot of legacy hardware and software that would need to be updated if the current UTC definition were to be changed.
Because societal official/legal time is based on UTC and not on TAI. So the point is to change societal official/legal time, not just to use different time standard.
>It's frustrating that programmers want to redefine civil time just because it is "hard". This article glosses over the real world problems that detaching from UTC will cause.
Yes, the actual problem exists, and ignoring/discarding reality (i.e. the "science" in computer science) will just cause further problems. If you and your modern stack of code can't handle the leap second, it's simply not production code.
Moreso: it is not a problem that dealing with the nuisance that is leap seconds even solves. It is supposed to match civil time to astronomical time, but astronomers don't use it. It just makes things even more annoying for astronomers, and annoys everyone else, over and over again, for no benefit to anyone.
> It's frustrating that programmers want to redefine civil time just because it is "hard". This article glosses over the real world problems that detaching from UTC will cause.
I agree, but I'm also - sad to say - less than surprised to find engineers at a Big Tech firm taking a high-handed, not to mention narrow and ill-informed, approach over the issue and trying to impose their will on a global scale. My worry here is that, Meta being Meta, they carry quite a lot of influence and may actually gain some traction.
EDIT: I'll add a bit more colour here. At the core of our platform we manage a database containing billions of legacy timestamped records (or events, if you prefer), adding more and more every day. Without even giving it a great deal of thought I guarantee you that this proposal will cause us more problems that it solves and will distract us from making more valuable investments of time and effort that would benefit our business should it be implemented. Sure, we can no doubt fix all these problems, but we've got better things to do. I imagine that many other businesses would be similarly affected and would take a similar view.
That’s all it is, they ran into an engineering problem and they’re trying to get the world to bend to their will instead of solving the problem because they think it will be easier. Mark’s arrogance is nauseating.
Now expand this reasoning far beyond the scope of time keeping.
Big Tech companies/Anti Big Tech lobbyists massively oversimplify in their pitch to influential people to deregulate/overregulate certain areas. In both cases they end up making poor decisions for the general case both end up making the average case worse for everyone except themselves. It's about creating a market where none need exist. Facebook doesn't need to care about time really. It's not remotely important to their business.
I've built and worked on platforms with sub microsecond measuring requirements and this stuff didn't bother me. This is idle bad money finding work for itself at the expense of everyone else.
Disclosure: I am/was an early investor in facebook in 2012. Mark is turning it all to dirt because he's run out of ideas
We have three alternative time systems and a big bag of issues with each of them, but you think the extremely mundane argument that we should prefer one bag represents nauseating arrogance because you think that your favorite bag -- a different one -- is obviously correct? Come on. Do better. Be civil.
FB is not making the mundane argument that we should pick one time system over another. They are literally proposing that the world should redefine UTC to be TAI with a permanent fixed offset, which is functionally equivalent to just using TAI.
That is effectively proposing the deletion of the most commonly used time system of the three primary time systems from existence and forcing everybody and all existing systems that use it to convert to what is effectively TAI.
That is not mundane. Mundane is arguing that everybody should use TAI. Arrogant is arguing that we should force everyone to do it by redefining their dependencies under them.
No, it is a change that breaks everybody using UTC correctly, TAI with a offset to synchronize with UT1, in order to fix everybody who did not know what they were doing and used UTC when they actually wanted TAI.
If there was a scheme that fixed only the wrong usages, that would be fine. But, it is frankly absurd that we should even consider breaking carefully designed programs correctly using their dependencies to fix programs incorrectly using their dependencies especially when it is trivial for the wrong usages to be fixed manually.
No, UTC is TAI kept in sync with UT1. Changing UTC to being TAI with a offset is a fundamental breaking change in what it means. Anybody relying on UTC doing what it is designed and advertised to do, keep in sync with UT1, will be broken. The only people who will not be broken are people using UTC incorrectly as TAI. The only reason this is interesting is that basically everybody uses UTC incorrectly as TAI, but that is not a valid excuse to break the programs using it correctly.
People using the wrong dependency should fix their system to use the right dependency. They should not campaign to steal the name and replace it, that is absurd.
Literally nobody depends on any relationship between UTC and overhead sun angle.
The only people who care or need to do not use UTC. They use TAI, and a separate continuous log of fractional seconds.
UTC has one role, and that is Standard worldwide civil time. Telling people who need Standard civil time to use TAI makes everything strictly worse: not only do you then not match most of the world, but you still have to track irregular, unpredictable corrections to be able to sync with everybody else.
Except that standard civil time cares about the overhead sun angle for some reason, that is why we use the day demarcations of UT1 instead of TAI. If we really decided as a society that we really no longer care, then we should switch standard civil time to TAI and do away with UTC entirely, not calcify it as some arbitrary offset from TAI.
> "cares about the overhead sun angle for some reason"
That is what is proposed to be fixed and that you are arguing against for reasons you don't know or, apparently, care about.
Switching civil time to TAI would break everything, most of which cannot be fixed. Random breakage is the problem. More breakage would be strictly worse.
Well we could introduce negative leap seconds until they align. The problem (UT1 deviating from UTC by more than one second) would be the same as in this proposal.
> Literally nobody depends on any relationship between UTC and overhead sun angle.
That's just... completely incorrect and totally false? Have you ever even worked for a business? Have you ever read how time libraries are actually written?
It is literally built on the exact assumption that 0 means January 1, 1970 and that right now is (number of seconds in a day) x (number of days since Jan 1 1970). If we stop adjusting UTC, then by this time next year UTC will be one second out of date with our wall-clock times, and calling `datetime.now().isoformat()` will give us a timestamp that's 1 second off from the wall-time of a user. At one-second past midnight on the 20th of the month, your computer will incorrectly be spitting out timestamps saying it's exactly midnight of the 19th. That's what you might call a major breaking change.
I'm kinda impressed by the hubris, really. Usually it's emperors, kings, and big multinational governing bodies that try to screw around with the time standard that ordinary people have to live with. Occasionally strident revolutionaries who've already solved the "overthrow and replace the government" part of their problem and aren't content with just beheading people all day.
Says something about how Facebook sees itself, I guess.
>Your honor the nuclear attack on San Fransisco happened at 10.59.59 as per UTC-Facebook time and is as such part of WWIII and not a violation of the armistice.
By "UTC-Facebook" time, you of course mean UTC time, the time everybody already uses, and that has no need to be broken every year, two years, or three years, and wouldn't be broken at all if we simply stopped breaking it.
By a foot you of course mean the foot-meter, a measure good enough for everyone and one which will stop breaking metric conversions if we just defined three feet to be a meter.
> I totally don't care about the Earth slowing down.
Neither do I in day to day life. But I do have to care about it when I or members of my team write code, or store and retrieve data to and from a database, or work across multiple timezones, because it can be critically important to unambiguously know whether something happened on one day or the next.
The reality is there aren't any nice, elegant solutions to this problem. Leap seconds aren't a nice solution. Meta's proposal isn't a nice solution. I don't necessarily even think it's worse than leap seconds, but it's certainly not substantially better. The key point is it's a change and one which, in my view, won't deliver enough value for everybody (beyond just Meta) to justify the level of disruption it will certainly cause if implemented.
Lot's of folks care, what are you talking about? Accountants and lawyers the world over EXTREMELY care about keeping the computers idea of wall-clock time and your idea of time in sync, and if you're a customer faced with the side-effects of changing the standard after-the-fact, you probably care as well.
Let's paint a picture based on actual code I've actually seen in the real world. If you ignore the leap second but keep using UTC, then in about 5 years, UTC will differ from wall clock by about 5 seconds. So if, in some software used for, I don't know maybe billing customers, someone was calculating day boundaries by doing modulo division of UTC by the number of seconds in a day (I've seen it), then in 5 years we've got a 5 second discrepancy in the number of API calls made by customer X when comparing what the software says to what the customer measured. Customers don't like this, accountants and lawyers REALLY don't like this, and us engineers will have the wonderful experience of telling them all
> "this code used to be valid until some boneheaded engineers at Facebook convinced a ton of other engineers to break the agreed upon standard about what it means to measure time in this way, and now things that used to work fine need to be patched because we've got a Y2K EVERY DAY!"
Oops, I guess ignoring wall clock time might be something other human people care about after all.
> By 2055, the "minute" displayed on a clock may be incorrect, which again may cause issues with legal timestamps.
I'm not following here. What defines "legal timestamps" in our current system? I'm unaware of any laws in the US that uses the actual position of the sun to determine the time.
"Noon" when the sun is at the highest point, can vary over an hour across a timezone.
Way more than one hour. Even without taking China into account, A Coruña in Spain and Kosice in Slovakia are in the same time zone but they are 30 degrees (2 hours) apart.
A birthday is a legal timestamp. A car crash is a legal timestamp. When the time is off by a minute, these events can’t be catalogued correctly any more.
Shifting the timezone by a couple seconds does not prevent or hinder cataloguing events in any way whatsoever, certainly not more than switching to daylight savings time does or the mere existence of timezones, which may easily be half an hour or even more off from the solar time - the offsets we use for time are effectively arbitrary already, and adjusting the arbitrary choice of the offset by some seconds is not a fundamental difference. Event timestamps already map to different days depending on different timezones, you do need to know which timezone your clock is using, of course, but you already need to do that.
For people born just around midnight, especially around new years eve, a few seconds could impact their DOB by a whole year. This could affect everything from university applications to boating licenses to social security.
Some countries have boating license laws that are different depending on whether your DOB year is >= 1980, as an example for this type of "grandfathering cutoff".
Both can easily be placed on same monotonic time. Actually makes a things simple. You don't end up having 31/12/1972:23:59:60 and wondering why is there 60 there...
Maybe you seem to think that was is being asked for is to retroactively remove leap seconds from UTC? That is not the case, all that is being called for is to stop adding more leap seconds.
> If we end leap seconds, it doesn't take long - only until 2028 - until "midnight" is sufficiently far from "the middle of the night" that you will have to consider the legal issues caused by events that happen just before or after 0000 hours.
I'm not sure what you're getting at here. If we stopped introducing leap seconds, then why would the legal world still care about them?
I can believe that a desperate lawyer would argue the semantic distinction between clock-midnight and solar-midnight, but I have trouble believing that this would amount to anything more than one more dumb nit on a pile of dumb nits that the court has to deal with every day.
They can already argue that though, since solar-midnight is not the same as clock-midnight anyway due to timezones. Really, timezones already create this difference for the majority of people, and to a much larger degree than leap seconds likely ever will.
There's no need to "detach" from UTC. Just ensure that TAI (which is consistently free of leap seconds) is also supported on an equal status to UTC, for applications where it makes the most sense. Conflating the two would only increase confusion further.
Programmers can already do this if they want to. TAI already exists. But they'd have to still display UTC as civil time to end users and I'm pretty sure they don't want to do that either because it would mean just as much code.
the hard thing about TAI is that it’s not properly supported in DBMS, RFC 3339/ISO 8601, etc… This makes it hard to use. It’s actually easier to use MJD represented as a double.
"Make two parallel time systems and allow conversion between one and the other programmatically" reduces spiritedly and unambiguously to "use one time system and care for it programmatically".
By precedent, UTC seems the logical choice for the one time system.
But the whole point of the OP is that UTC has leap seconds, which are hard to manage programmatically - and may even be impossible, wrt. future dates and times. That's literally the one relevant difference between UTC and TAI.
There is no need for UTC to continue inserting leap seconds. When they commit to stopping, everybody can relax: irritation removed.
Telling people to use TAI is telling them to have a different time from everybody else. The whole point of civil time is specifically that other people use it. Using TAI does not free anybody, because anytime you need to interact with outside, you are back in the nightmare.
Exactly. Discontinuing leap seconds is a 99.999999% compatible change.
I've tried to build systems using TAI they break down because: At some point you have to interact with something that doesn't use TAI and that fully reintroduces all the leap second issues, and because a lot of third party software has leap second handling, so the wheels fall off when you update some component and its embedded list of historical leapseconds now changes its behavior. Similarly, sometimes UTC time is all that's available and without the leap second data you can't back them out to get TAI.
And with leapsmear the challenges of backing out to TAI have increase substantially.
If you stop thinking about time being wrong from what is officially correct, and instead see this whole exercise as a error minimization framework I think it is far easier to make the case for ending leap seconds as it is for keeping them.
This isn't just about lines of missing code. This is about forcing subterranean or submerged computers to surface. This is about out of sync clocks across information propagation networks across planets. This is about real lives that are ruined because time stamps didn't quite line up, causing delays, deaths, and needless headaches.
It doesn't need to be this way. We could just accept a minute of the clock being off from "true" midnight, which doesn't even make sense to me given that few people are right at the astronomic point where midnight is "true" midnight for their timezone. Heck, China is one big giant timezone so who is this actually for, really? The people that care about sundials? Most people don't even grow their own food.
We're no longer a sun-driven economy. Well coordinated timekeeping across devices that may not always be able to transfer data is far, far more important. If it's sufficiently wrong by the year 3422 then we'll deal with the fifteen minutes of annoyance then. This is a crazy premature optimization.
> Well coordinated timekeeping across devices that may not always be able to transfer data is far, far more important.
How do you have a well coordinated clock without being able to get four bits [1] per year of leap second data? It's hard to keep within one second of a time standard over 6 months or a year without communication.
[1] bit 0: was there a leap second in the most recent period, bit 1: was it positive or negative; bit 2: will there be a leap second at the end of the current period, bit 3: will it be positive or negative. Bike shed my fictious encoding if you like, but it's good enough. Use a whole 8-bits, go wild.
Cesium reference clocks can operate with accuracy around 10^-14 (aka 0.01 parts per trillion). In a year, a cesium clock would slip by a few tenths of a microsecond. That said, the whole "submerged computer must surface" thing is a bit of a red herring argument IMO. What use case would you have for needing to keep time in sync within seconds with the outside world, but being unable to communicate with that world? If you're trying to plan simultaneous delayed action across the world, it would suffice to merely be in sync with each other, leap seconds ignored.
The chip-scale atomic clocks were developed to support precise timekeeping for small devices that can’t communicate. One example is undersea sensor networks, where you want to leave the sensors in place for a year or more, and when you return you can correlate the readings from the sensors because you know they were all ticking at the same rate the whole time.
“civil time” is also a construction that is flexible in many ways, so an influencial group redefining it isn’t out of norm. To note, timezones were introduced for railway purposes, and some country play a lot with them.
For “midnight” being far from “the middle of the night”, that’s already a reality for many Chinese living far enough from Beijing, or god forbid regions where “night” doesn’t mean much for half of the year.
For all intents and purposes, if a formal definition of time isn’t practical people come up with their own ways.
I think that observation just lends further weight to the argument that the relationship between atomic time and universal time is a dynamic and unpredictable thing, which we need to handle correctly rather than pretending it doesn't exist.
That it is dynamic and unpredictable is exactly why we should not force everybody to track it.
Some people: astronomers and orbital mechanicos are obliged to care about sidereal time, regardless. Making me deal with it too is pure tax with exactly zero benefit.
When the sun is directly overhead it's meant to be 12:00 - IN THEORY!
However as Timezones are pretty wide, most of the time you'll be at least 15 minutes out. Sometimes you'll be out by as much as 3 hours - and you've probably never even noticed!
Telescopes already have to compensate for this (as well as for summer time).
Leap seconds make a shambles of book keeping too. What is "2022-07-17T12:00:00" + (60 x 60 x 24 x 365 x 5) seconds? No one knows! And the answer to that question will change depending on when you calculate it and which updates you installed!
So I say ditch the leap second and let it drift. In a few hundred years we could update our timezones if we _really_ want to (timezone changing is actually pretty common, so code should already be handling this edge-case).
Please consider that none of this actually matters if we ditched UTC for TAI. For one, time zones still exist and local solar time is already decoupled from clock time.
I'm honestly amazed to see so many people agree with this.
Timestamps are exactly what we define them to be. There is no correct and incorrect.
One option is to have a system with arbitrary unpredictable leaps to keep it synchronized to within 1 second of the mean solar time over Greenwich, England. Every computer system that has to deal with time accurately needs a lookup table for leap seconds that is occasionally amended, with only a couple months warning in advance.
Another option is to just let the clock run at a constant rate. In this case only astronomers have to keep track of the difference between solar time and clock time (which they already do anyway).
The fact that the difference will increase to an hour after several hundred years is utterly irrelevant. If people in the future care, they can simply adjust the timezone definitions to compensate, since timezones are already adjusted all the time.
> It's frustrating that programmers want to redefine civil time just because it is "hard".
Yes. Problems with delay time going negative usually come from not using CLOCK_MONOTONIC for delay time. CLOCK_MONOTONIC is usually just the time since system startup. It comes from QNX (which, being hard real time, had to deal with this first), made it into the POSIX spec around 1996, and is now available on all major OSs. But there's still software that uses time of day where CLOCK_MONOTINIC is needed.
Then there's the smoothing approach. This document described Facebook's smoothing approach, which has a different smoothing period than Google uses.
* Facebook/Meta: "We smear the leap second throughout 17 hours, starting at 00:00:00 UTC based on the time zone data (tzdata) package content." This is puzzling. What does the time zone package have to do with UTC?
* Google: 24-hour linear smear from noon to noon UTC.[1]
* AWS: Follows Google.
* US power grid: Starts at midnight UTC and takes a few hours while all the rotating machinery takes 60 extra turns to catch up.
> What does the time zone package have to do with UTC?
The IANA TZ database includes information about leap seconds, and even supports the concept of "right" time zones in which the leap seconds are counted in the Unix timestamps. (Which violates the unix spec, and may cause problems with code that assumes it can do path like `1 day= 24*60*60`, but on the other hand, things like DST already make that unsafe).
It is mostly likely simply the case that they are using the leap second data from the time-zone database as a convenient source of this data.
> In about 600 years TI will be ahead of UT1 by half an hour, and in about 1000 years the difference will be a full hour.
That's nothing. Time zones alone already create significantly larger errors. Belgrade and Sevilla share a time zone, but the solar meridian ("noon" on a sundial) is 12:44 in Belgrade and 14:30 in Sevilla. Obviously, the same error is present in the astronomical "middle of the night". This does not, in fact, create "legal issues" for Serbs or Spaniards.
In 600-1000 years, around the time that it would actually matter, we're going to have to reform the time system anyway to account for relativistic drift between the surface of the Earth and human settlements elsewhere in the solar system.
We live in a world where civil time moves by an hour 2x a year for no good reason.
You FAR overstate the impact on civil society of failing to change it by a second every so often.
Ironically even astronomers, who leap seconds were originally for, don't benefit because they need to know the Earth's rotation accurately to subsecond levels.
> it doesn't take long - only until 2028 - until "midnight" is sufficiently far from "the middle of the night"
Honestly from my perspective, 3am is the middle of the night (night-morning-afternoon-evening starts at 0-6-12-18 for me) and somewhere between 4 and 5 most people are probably asleep and the date change should occur. I can't count how often I've heard people clarify what 'tomorrow' means when the word is spoken after "midnight" but before going to sleep.
But yeah gotta pick something for the date change, it won't be worth the cost of change now. If we do end up ever switching to something like decimal time, this should be on the todo list though.
And I know "midnight" is historically supposed to be about the sun being the furthest from its zenith rather than in the middle between when you go to sleep and get up, however that occurs somewhere around 1am here (01:41 at its extreme, from July 17 till August 5th). If that's not enough to warrant a redefinition, 27 seconds accumulated since we started counting leap seconds are also not enough to warrant an update yet (following Facebook's logic here).
These "problems" are trivial. The day changes at midnight which is 12:00 AM by the clock. There is no ambiguity. Midnight is not literally the middle of the night. The minute on the clock will be correct by definition, nothing will change. Sundials are already wrong. You'll need to try a lot harder to convince me that this is a bad idea.
All these arguments based on sun position make no sense in a world where people already live in places where the sun literally never sets or never rises for months, and people already live in time zones offset many, many hours from "correct" time. The sky doesn't fall!
I don't see how you run into legal problems. The break from one day to the next still occurs at a well defined time, 23:59:59 + 1 second, or 00:00:00. Midnight isn't the middle of the night (or noon exactly at solar zenith), except on 15deg meridians anyway. What will happen is that over time, those "golden" meridians will shift slightly. The only people who will notice are those that are using time for celestial navigation. Terrestial navigation, which is almost entirely done with GPS these days, won't be affected at all (GPS already doesn't use leap seconds). And, yes, sundials will gradually get out of sync, and have eventually to be rotated on their axis to be right.
* "Most telescope pointing systems fail" (by 2027) (with 5s deviation from earth rotation). Pointing systems cannot blindly rely on UTC anyway, since (a) even with leap seconds UTC is up to 1 second off earth's rotation, and (b) pointing a telescope depends on where the telescope is on earth, so some offset must be added to UTC by some human.
* Hypothesized legal issues... give me a break.
It would be much less trouble for humanity to deal with this once every 100 years or so.
> only until 2028 - until "midnight" is sufficiently far from "the middle of the night" that you will have to consider the legal issues caused by events that happen just before or after 0000 hours.
I can't follow your logic here. In any relevant context midnight has a definition, typically UTC midnight in the applicable timezone. Eliminating leap-seconds would make the instant midnight occurs less ambiguous in 2028, because precise timing with leap-seconds is strictly harder than without. (and one can independently realize a time that closely follows TAI but one cannot independently realize UT1 without a VLBI radio telescope array, and one can't realize UT1-TAI without a datafeed because the decisions are subjective).
This isn't just a question of 'some lines of code'. Leapseconds cause widespread disruptions even when they don't occur, they cause security vulnerabilities (and slower and less secure systems because they make synchronization unreliable). People are widely deploying "leap smeared" NTP servers to try to prevent some of the worst synchronization faults, but doing so makes it impractical to back out leap seconds to derive TAI (or a more accurate TT) from the system's UTC, particularly because systems don't know if they're leapsmeared or not (and different smear sources use different smearing parameters).
Why does ntpd lose the smear on a restart? I would have thought that the current smear could be calculated purely based off current non-smear time, plus the config to say when to smear, which is presumably available upon restart.
Also, why were non-linear smears thought to be desirable? Googling just turns up hand-wavy phrases like "easier on clients".
That was my thought too, pointing out why NTP smearing might be fragile is a crucial point in any argument against leap seconds, and the reasoning in this post are lacking (regardless of the conclusion's correctness).
My only guess is that because smearing takes place at Stratum 2, if the network partitions part of the NTP servers downstream (Stratum 3+), they'll have an offset as large as T/(17 x 3600) (T being the partition duration in seconds).
Yet I guess it must be something else for I cannot see why that won't be tolerable.
More generally AFAIK the NTP RFC does not include smearing period, which is why the best practices are to only use smearing in a well controlled environment rather than on public facing NTP networks, but why is this not something that can be fixed? I'm not sure.
Weird, I came to a different conclusion after reading the article. There's already a graceful solution to non-monotonic time, which mitigates most of the problems: smear, don't leap. Only, it's not a universal solution, so various systems are out of sync during the smear. Solution: petition for a standardized smearing strategy. But yeah, leave "leap" seconds in the past.
And, maybe, don't run sub-second benchmarks with a wallclock.
If smearing were adopted as standard, the "seconds," "minutes," and "hours" appearing in timestamps would no longer correspond to literal seconds minutes, and hours of duration, even in principle. That seems very misleading and bad.
Smearing is absolutely the worst of all possible choices. Instead of one second, you are out of sync with the whole world for all of 24 hours. And you are fooling with things for the whole period.
Of course it was Google who picked the worst of all possible choices.
But, its practical success does in many ways prove that mild inconsistencies between different time systems are...fine, and so a leap-less approach wouldn't cause any issues.
So what's the alternative? The leap second is capturing an actual skew between uniformly-ticking clocks based off of atomic decay statistics and the rotation of planet Earth. Stop updating them, and we end up with the sun going down for equatorial latitudes at 3PM eventually.
This feels very can-kicky, even if the can can be kicked a thousand years down the road. I don't think more can-kicking is really the best solution.
So their complaint is that one-second skews happen infrequently enough that they are always a headache, and we want to "solve" the problem by... Replacing it with a less frequent time modification that introduces larger delta?
I've been on the front lines of adapting code for a novel timezone change. It wasn't pretty.
It is not, ever. Doing it every year or two imposes just as much disruption every year or two. A disruption once a century is at least 50 times less disruption.
When the problem is “this is too hard for us (but apparently not our peers)”, a valid solution is not “let’s just ignore it, even though our idea would cause an enormous pain in the neck for the rest of the world”.
Why do you think it's not also too hard for their peers? Any company with an interest in time keeping spends tons of money dealing with time zones and leap seconds.
Because I haven’t seen the Google or Amazon proposal to ditch it. Perhaps they’ve written them and I don’t know about them, but I’m not aware of them.
We do lots of things that are hard because doing them right is often more important than doing them easily. Switching from ASCII from UTF-8 was a pain, but we did it. Software upgrades are a pain. Security infrastructure is a pain. Timezones are OMG such a pain. But in all those cases, we collectively said “welp, guess we’ve gotta do it”.
And what Facebook notably didn’t propose was a way to actually make this happen. Who’s going to project manage the global coordinated effort to migrate the planet to Facebook Time? That sounds like much more work than them just fixing their time handling.
OK, so I do agree with that. It’s worth having a conversation about.
But I don’t feel like this rose to the level of an actual proposal. It was very short to assert a claim with such wide-reaching implications as “we should start ignoring leap seconds”. As such, I don’t think it calls for an in-depth rebuttal.
Consider:
Proposer: “It’s time to leave Unicode in the past. It requires us to update every part of our system to deal with UTF-8 strings instead of much simpler ASCII, and we’re spending a lot of resources. Because it’s so hard and expensive, we should all use well-tested ASCII code. People who want to interoperate with our system can just rename themselves to use the Latin-1 alphabet.”
Everyone else: “No.”
Yes, it is hard, and people have spent a lot of, ahem, time and money to figure out how to manage this at scale. But there are real-world-tested approaches to dealing with the issue, and I firmly believe it’s better to work out and coordinate on the remaining rough edges than to throw the whole thing away to make a handful of engineers’ jobs easier.
It's not just Facebook: apparently in 2015 most countries wanted to drop leap seconds, though some wanted to keep them: Most countries, including China, the United States and many in Europe, favour scrapping the leap second and basing UTC on the continuous tick of atomic clocks. -- https://www.nature.com/articles/nature.2015.18855
If the solution implies de-engineering society from first principles to satisfy a programmer’s desire for regularity, it’s more of a thought experiment than a solution.
The world is messy, life is messy, and so is everything else. If that’s too much for poor programmers, they need to find another job.
TFA explains that it largely doesn't matter if we just ignore the leap second. It's additional complexity to our timekeeping systems that doesn't buy us much (if any) value. All the super-precise systems which would be impacted by being one second off ignore leap seconds anyways.
And god forbid we respond with "that's not a good solution." To restate, here's the problem, quoted from the original article:
> "As an industry, we bump into problems whenever a leap second is introduced."
Their suggested solution is:
> "As engineers at Meta, we are supporting a larger community push to stop the future introduction of leap seconds and remain at the current level of 27, which we believe will be enough for the next millennium."
Most folks are rightly pointing out that there are many other solutions that we could introduce, which wouldn't have the downsides of UTC drifting away from our wall-clock time. Facebook didn't even discuss those solutions though.
An example possible other solution: programmers (especially programmers at Facebook) should stop using UTC and should instead use TAI (which is literally UTC but without leap seconds). Indeed, using UTC time as anything other than a wallclock time should trend towards the norm. Even though this is a clear tru-ism, seeing it adopted would be way harder (due to language inertia and habits) compared with just changing the standard (nevermind that changing the standard would break a ton of logic built around expectations like "midnight UTC falls on an integer multiple of 86400").
The problem is that UTC, despite its name, is not a time (it is an angle rounded to a multiple of 1/21600 right angles).
Only TAI is a time.
Already decades ago, some programmers have argued that internally all computers and their software should use only TAI, which is a time, so it behaves as expected, while UTC must be used exactly like the local times and the time zones, only at the interfaces with humans.
If that proposal would have been adopted, there would not have been now any discussion about the leap second.
The only reason for the existence of UTC is to keep dUT1, i.e. UT1 - UTC, under 1 second.
If the leap second is eliminated, then dUT1 will grow over 1 second, so there are other cohorts of hardware devices and software applications that must be updated in order to no longer rely on the assumption that dUT1 is less than 1 second.
Anything that has any relationship with astronomy, e.g. for observations or for navigation, relies on computing UT1 (i.e. the angle between the mean Sun and Earth) from time, so it would have to be updated.
Changing the definition of UTC would make it completely redundant, Instead of giving up to add leap seconds to UTC, it would be much better to make a final leap of a half of minute and have TAI = UTC after the date of the big leap.
Having 2 identical times with an arbitrary offset between them would just add needless complications to all time-related software, forever.
> The problem is that UTC, despite its name, is not a time.
Could you elaborate on what you mean? What is UTC if not a time? Like, datetimes vs time?
Even if Unix time was based on TAI, you'd still need leap seconds in order to resolve the correct local time (which is based of even-minute offsets of UTC). Maybe it's easier to deal with in calculation post-hoc vs smearing on the day of, but that handful-of-accruing-seconds will always be there.
UT1 is an angle, i.e. the longitude of the mean Sun projected on the Earth.
The mean Sun is a fictitious Sun with a motion that is averaged in comparison to the real Sun.
UTC is the UT1 angle rounded to a multiple of 1/21600 of a right angle, i.e. the angle corresponding to 1 second of time for something that completes a circle in 1 day.
Because of this rounding, actually a truncation, UT1 = UTC + dUT1, where dUT1 is between 0 and 1 "seconds".
Even if UT1, dUT1 and UTC are expressed in "seconds", these "seconds" are not the unit of time, but like I have said, such a "second" is 1/21600 of a right angle or pi/43200 radian.
Both UT1 and UTC are angles that approximate the longitude of the projection of the Sun on Earth, with various accuracies.
Because the rotation of the Earth, which causes most of the apparent motion of the Sun, is almost uniform, the angle of rotation is almost proportional with the time, so the angle UTC is almost proportional with the time, i.e. with TAI.
Because of the way how the "second" angle used for UT1/UTC is defined, the approximate proportionality becomes an approximate equality of TAI with UTC, but because the equality is only approximate, there is an increasing offset between them.
In the ancient times, the people did not care much about time, but only about the angle of the Sun, which determined when it was light or dark, hot or cold, enabling or preventing various activities.
In modern times with artificial lighting and heating and with many activities that proceed at predictable rates, time has become much more important than the angle of the Sun.
In any case, in all contexts we must be aware that the angle of the Sun and the time are not the same thing, even if they are almost proportional, i.e. almost equal after a change of the measurement unit.
The rate of angular change divided by angle sure as heck sounds like units of time to me. The absolute angle isn't, but the rate of change is, and UTC still tracks with rate of change, with a phase angle we periodically twiddle.
That's like saying a watch or even an atomic clock doesn't measure time, it measures oscillations. It's being pedantic to the point of obtuse.
Except, astronomers do not use UTC now. So its sole supposed benefit completely misses the tiny slice of people it is supposed to be for.
UTC has exactly one purpose: to be a common reference for everybody else. Making it not mess up everybody else, every year, is obviously the better choice.
You may stop beating your spouse now, and it will be purely an improvement.
Having made the mistake 27 times already does not justify making it even a single occasion more, never mind forever.
Situation: there's a problem, and our current way of coping is something we've done 27 times so far.
Reaction: let's stop using the system we have some practice at doing, and instead open up the question again, but really just have big tech corporations dictate to the world that we need to do something else.
Might be before many people's memory here, but Swatch tried to create an "internet time" in the late 1990s. Nobody uses it because it doesn't solve any problems anybody has, it's just different.
Fun thought, we have only ever had positive leap seconds so far, due to slowing of the Earth's rotation. However, we could have a negative leap second. The rotation has just been consistently slowing since we started caring. But it could speed up again the future. We can predict rotation speed to a certain degree, but not completely. That is why leap seconds are announced only a few months in advance, instead of years.
I don't think we will ever need a negative leap second. We can just wait longer until dispatching the next positive one. The only situation in which we'd need a negative leap second is if Earth's rotation were consistently speeding up over many years. But we can tolerate some wiggle room (as in, several seconds) between UTC and TAI (since it's not in lockstep anyway).
The problem is that there are hardware devices and software applications, which compute UT1 (the angle of the mean Sun) from UTC and from dUT1 (which are transmitted both on various communication channels, e.g. by radio stations) and all those expect that dUT1 is a number between 0 and 1 seconds.
If dUT1 can become either negative or larger than 1, all such hardware and software must be reviewed and possibly upgraded, to no longer make assumptions about dUT1.
Communication protocols may have to be changed, if there is no way to encode a negative dUT1.
> If dUT1 can become either negative or larger than 1,
Negative values should already be accounted for, afaict.
> UTC is maintained via leap seconds, such that DUT1 remains within the range −0.9 s < DUT1 < +0.9 s.
I can't imagine why it would ever be constrained to abs(dut) < 1, as that does not appear to be a hard spec anywhere, it's just the goal. But I could see some really stupid implementations, so maybe.
UTC and TAI are already over 30 seconds apart. So not using a negative leap second to keep them aligned isn't really a valid argument. On a geological scale, Earth's rotation is slowing down, but on a decade scale, it's still pretty chaotic. We could just as easily be having the reverse conversation. When we need a negative leap second, we may need a few in a row. So just waiting for a positive one to cancel them out doesn't really work. Using the logic of it will all eventually be a wash and we shouldn't use them at all is kind of the argument the article is making.
Can't help but agree with 80% of this post but strongly disagree with the solution. This feels like a hack that punts the problems to the future.
UTC has the leap second cause it's not "real time" and so now we're just gonna never sync up UTC to real time at all? How is that the solution? Either we deal with leap seconds or we need to implement something that can't go backwards and properly models time. Leap seconds seem much simpler...
In the end we didn't get rid of SQL cause of SQL Injection. We fixed the frameworks and promoted the solutions. We may simply need to make a push for languages and etc to just properly support time and promote how to do things correctly. It honestly seems easier.
> we need to implement something that can't go backwards and properly models time
There simply is no definition of solar time that can obey this constraint long term, because the rotation of the earth varies, and varies over time in ways we have a limited ability to predict. This is the entire crux of the problem.
It is not the crux of any problem, except for, uniquely, astronomers.
But they have their own solution we need pay exactly zero attention to. Leap seconds in UTC are just as big a nuisance for them as for everyone else. They have TAI, sidereal time, and this dumb bastard UTC with its own hacked up thing that doesn't match their precise alternative.
It's not a problem for astronomers. It's a problem for everyone. It's a small problem for everyone today. And it will remain a small problem for a long time. Eventually it will not be a small problem.
Meanwhile, making sure everyone agrees as to the kind of time they're talking about it hard enough.
Everybody has already settled on UTC. All we need is for UTC not get fucked every 15 to 30 months and break about half the systems that need to communicate with each other.
If they stop announcing leap seconds, everything correctly equipped for leap seconds will still work, and everything else that gets it wrong every time will also work.
And those of us who have to make the stuff that works right adapt to all the crap that doesn't and can't be fixed can do other things, instead.
You seem to have missed that everyone is already on UTC, and will not change to satisfy your sense of esthetics.
Fixing UTC by simply not declaring any new leap seconds eliminates all problems. What used to break on a semi-regular basis stops breaking. Nobody suffers. Nobody pays. No problems surface.
Having read a lot of the comments here, I tend to agree with you.
Leap seconds have not sit well with me ever since I learned about them. Messing with the number of seconds in a certain minute a few times a year just seemed ... unclean.
So if fellow commenters are right, that without leap seconds it would take 6667 years for the time to drift just one hour, then leap seconds are absolutely more trouble than their worth, and we should drop it this instant and try to come up with a solution for that leap hour in the next six milleniums.
If you don't want leap seconds use TAI. If you do want leap seconds use UTC.
This is like people saying that we shouldn't have daylight savings so we should redefine GMT to not have DST. That is not only stupid but breaks all use cases where you care about historical DST.
This is why we have UTC, it's GMT - DST. People in 1960 could figure this out. Are we so incompetent that our grandfathers were better programmers than us?
I'd argue that TAI has far more right to the term "real time" than UT1. The Earth's wobbling and halting deceleration should not impact, let alone underly, our definition of time. UTC agrees with this assessment almost always: it tracks TAI except for leap seconds that prevent it from de-syncing too far from UT1.
TAI > UTC > UT1
That said, the hard work to build out a compromise has already been done, so whatever, let's just keep it until political or speed-of-light issues make it awkward to distribute information about leap seconds, at which point dropping them will be an easy and natural solution.
> The Earth's wobbling and halting deceleration should not impact, let alone underly, our definition of time.
Who's definition... the whole relativeness of time means this is a problem.
Yea, I agree that we should have a unit of time defined for things near sea level and not moving very fast. But even that becomes problematic over 'long' periods of time as the earth is slowing down and will skew from what humans experience, of which has been the basis of how we define time until recently.
Even then we're still leaving out the problems of things in space and on other planets.
At the end of the day we're attempting to define time as something exact for all observers, and when you attempt to give an exact definition to something that is not exact problems are going to occur.
It's natural to distinguish between wallclock time and duration time; or, time used to fix events chronologically and time used to figure out how long to do something. The first kind of time is the only plausible use case for leap seconds, because if you insert a leap second into the command "run main motor three seconds" you're going to be in a lot of trouble.
> The Earth's wobbling and halting deceleration should not impact, let alone underly, our definition of time
If you define time in terms of days and years, I.e in term of revolutions of the earth around the sun and itself, of course it’s wobbling and deceleration has an impact. If you think it shouldn’t then measure time differently, for example as seconds since a certain instant
> If you think it shouldn’t then measure time differently, for example as seconds since a certain instant
Isn’t that what the article is arguing we do? What practical benefit does keeping this historical definition of time give us? Outside of people trying to account for the rotation of the earth precisely who could even notice?
Sounds like it would be massively simpler for the users who need to use time like this to deal with leap seconds rather than require that all software deal with it all the time
It would take thousands of years for UTC-without-leaps to shift an just an hour. Our timezones are often wider than an hour.
If you really need a 'solar-ish' time, you could also define a fixed function correction for UTC->'solar' and then extend that thousands of years by an order of magnitude. (Sadly the SI second is somewhat far off from the 1/86400th of a solar day, so a big portion of the correction caused by leapseconds is just this predictable portion of the difference).
> If you think it shouldn’t then measure time differently, for example as seconds since a certain instant
Plenty of stuff would love to do that, but we distribute UTC. To get back to "time from an instant" given UTC you have to know about and correctly and consistently handle leapseconds. It's quite tricky, because when an interface hands you UTC you don't know if the latest leapsecond has been processed in it. It's getting even harder recently because the widespready distributed systems failures caused by leapseconds are causing some people to deploy varrious kinds of "leap smear" which smears out leapseconds over some number of hours. Interfaces that are supposed to return UTC now sometimes return leapsmeared UTC with some unknowable choice of smearing scheme.
Arguably the root issue is that we've based out computer timekeeping hierarchy on UTC instead of TAI (or GPS time or whatever non-leaping thing). Had we based everything on atomic time and handled 'UTC' as a presentation layer thing like timezones are normally handled things would work much better. Unfortunately that ship has really sailed. Fortunately, if leap seconds are just not issued essentially everything keeps working without issue for hundreds if not thousands of years.
The handling of timezones and of leap-seconds are orthogonal problems, arising from distinct causes. Leap-seconds are a response to the desire to synchronise an atomic timescale with the uneven rotation of the Earth; timezones (and DST) are strictly a political problem.
Politicians often don't understand the consequences of timezone changes; they often introduce them without giving enough time for people to update their timezone database - sometimes just a few days. The result is that the new timezone is nothing more than a political gesture, because hardly anyone is using it.
Database drivers for mabny programming languages have something like Java's PreparedStatement which allows you to compile the SQL query together with code, before the application is ran. Whatever input is provided later by the user cannot result in SQL injection, because it is not parsed/compiled at all. So yes, SQL injection is a solved problem, it's up to you whether you know about/use the solution.
The SQL language is not flexible enough to allow preparation of every possible query, so the problem is fundamentally not solved. To take a simple example: query parameters are not supported in DDL or DCL statements, and in DML queries the usage of parameters is limited to values only: even such a simple thing as an ORDER BY clause cannot be controlled by parameter insertion.
"We have solutions for the most common occurrences" is not the same as "the problem is solved".
Depends if you define a solved problem as a problem with a known solution (theory) or as a problem people still pay the cost for in the wild (practice).
Anything Injection has a well defined solution of "properly escape parameters". deciding how time should be represented is a completely different issue.
UTC with leap seconds already does this. Leap seconds don't go backwards, they just alter the number of seconds in a minute. When the leap second passes, you have a minute with either 59 or 61 seconds in it.
The problem described in the article where "time goes backwaards" only exist when you compare two different time sources, which is always risky, whether a leap second is happening or not.
UTC is a count of seconds. Conversion to HMS is dictated to fool with the S field, but everybody suffers. The seconds count is supposed to actually skip.
UTC is not a count of seconds, because the standard representation of UTC does not have enough information to give you the right count. You also need to know the leap second table to convert a pair of UTC times to an accurate interval.
Because we are still correlating time with the rotation of the earth. Time is an absolute measure, a second is defined as a precise amount of time, and you can count the time that one event with that measure. Only historically the second was defined as a fraction of the day, and was correlated to the speed of the rotation of the earth, to this days we have better ways to define it.
Who said that time needs to be in sync with rotation of the earth? Nobody, who cares? It's a so small variation happening in a so long period of time to not be noticeable to any practice use: it's not that we take the sun as a reference of time anymore! We can keep counting time as we want and not be bothered with something not precise as the rotation of the earth. And for the applications that require that sort of precision, and only them, adjust the time accordingly.
I mean, a meter was once defined as the one ten-millionth of the distance from the equator to the North Pole along a great circle. It's not that for this reason if the distance between the North Pole and the equator changes we are all throwing away our meters... it's just that we found a more precise definition of one meter. Same happened with the second (and all the time measures, such as a day): we express them in a new format where it no longer matters what the earth and the sun do.
> Who said that time needs to be in sync with rotation of the earth? Nobody, who cares?
Humans sleep, usually at night time, and the rotation of the Earth defines night in any location, so regardless of the continual tick of some sort of "universal clock" we need a way to measure daily events that humans can use that rely on the sun going up and down at certain times and thus we need to adjust our local Earth times based on it's rotation.
Maybe we can decouple UTC (or whatever) from local times completely, so then a leap second is just a second we add to or remove from the offset for any given location, but we still need to deal with adjusting local clocks to the rotation of the Earth and it's orbit around our star, the "Sun".
This seems like a kind of navel gazing point, however-- without leapseconds it would take on the order of 4000 years to slip an hour, quite a big longer so that nights hours aren't aren't at night.
We already have a good mechenism for matching local sun time-- timezones.
I don't see anyting in your post to justify one second level offsets.
(aside, UT1 is technically defined in terms of earth's orientation with respect to distant quasars, not the sun :) )
Sleep is not influenced by a second before or more. And I never understood this, it's far simpler to adjust the time you wake up/go to work/go to bed/whatever than to adjust the clocks.
These solutions (including daylight saving time, timezone, etc) were probably a good solution where the clock were local and it didn't exist the problem of synchronizing clocks all around the world. But to these day, it doesn't really make a lot of sense sense. Even timezone, it would be far easier knowing that there is only a world clock (UTC) and we adapt our time to the clock and not change the clock.
Timezone, daylight saving, and leap seconds generate a ton of problems only for a minor convenience...
Eventually we will have to get used to having two clocks, slowly diverging.
It’s inevitable because we don’t want hours of slip on Earth and eventually we will move to other planets which certainly don’t want Earth leap seconds.
A lot of people in this thread are criticizing this move, but let me offer an opposite view.
One of the largest electronic health records systems has code that predates the UNIX epoch. Much of the time handling code is custom written to deal with this. However, the code was so poorly written that the system would lose data during the double 1 am window that occurs during daylight savings time shift. Hospitals would just shut off all of their computers during this time to deal with it.
As the article notes, issues with leap seconds have also brought down reddit and cloudflare. Many people in this thread are treating this like some sort of display of incompetence, but if you've ever written code that deeply interacts with time, you'd know how difficult it is to get right. A sign of a good system is one where it is difficult to fuck up.
IMO it is better to guarantee that time always moves forward rather than trying to match computer time to human time.
I don't see how replacing all UTC in software with TAI is more realistic than breaking UTC sync with UT1 (isn't it literally doing the same thing?). The whole point is that going forward, leap seconds are going to get harder to deal with. Especially in the case of a negative leap second, which seems like a more "true" y2k-like scenario.
The difference is that replacing usage of UTC with TAI is a voluntary choice made for each program, but redefining UTC to be a fixed offset relative to TAI, which is effectively just redefining UTC to be TAI, is a forced change on everything everywhere all at once that everybody has to handle because one of their dependencies changed.
It would be like silently changing the start of unix epoch time to 1800 instead of adding a new “Unix time since 1800” and asking people to switch.
Not at all. Everybody using UTC would just not need to deal with leap seconds anymore. A UTC second is the same as a TAI second. It's a no-op for the vast majority of UTC users. UTC will just drift slightly more from UT1.
This change only affects people who need UTC to be close to UT1 and also somehow don't know what UT1 is.
Sure, everybody using UTC when they actually want TAI would be a no-op, but then you irreversibly break everybody who actually wants UTC and assumed that UTC would not change meanings.
The people who would be unaffected by the redefinition can already just trivially switch manually (as we already assumed that just redefining things under them would work), leaving the UTC people alone. There is no good reason to silently break all programs carefully designed to use UTC correctly to fix all of the programs haphazardly written by people who did not know what they were doing and used UTC when they actually wanted TAI. Especially since fixing the wrong use of UTC is so trivial that we assume it can be done with no modification.
‘Programs carefully designed to use UTC’ would only irreversibly break by very slowly becoming out of sync with the rotation of the earth.
A few applications should switch standards, the question is whether solar concerned applications should switch to UT1, or continuity concerned applications should switch to TAI. The former is simpler, easier, cheaper, and only causes unexpected behavior (quite slowly), NOT systematic failure.
>IMO it is better to guarantee that time always moves forward rather than trying to match computer time to human time.
Not sure if you're playing Cunningham's Law or if you don't know this was the line of thought until everything was so far out of touch with reality, 10 days of time never existed, and official records were kept with dual-dates.
> However, the code was so poorly written that the system would lose data during the double 1 am window that occurs during daylight savings time shift.
> [...]
> Many people in this thread are treating this like some sort of display of incompetence, but if you've ever written code that deeply interacts with time, you'd know how difficult it is to get right.
Your example only speaks for the incompetence argument.
In reality, times and dates are really complicated. Luckily, the engineers at Facebook, Reddit, and Clouflare are being paid hundreds of thousands of dollars to show off their expertise. Is it that much to ask for them to read into details like leap seconds?
It is too much. I was Google SRE and there is an internal meme showing a time series graph jumping backwards during the double 1am at DST. These mistakes happen everywhere and are best avoided by a system that doesn't allow them to happen in the first place.
So advocates of memory safe (or even high level, period) programming languages are just showing off their incompetence in your book?
Would you say to an advocate of C (much less ... rust): Look man, real programmers write in boolean circuits. Programming is hard, sure, but the engineers at Facebook, Reddit, and Clouflare are being paid hundreds of thousands of dollars to show off their expertise. Is it that much to ask for them to read into details multiplication circuits?
:)
Leapseconds causing widespread failures isn't a hypothetical, just like buffer overflows aren't. Yet, in theory, with perfectly competent development ...
Yet even with perfect competence leapseconds are still pretty gnarly: They require systems have a trustworthy and consistent source of the list of leapseconds. ... and they mean that you fundamentally cannot predict the amount of time between two UTC timestamps when one or more of them is more than 6 months in the future... and no amount of competence can fix that.
If one is relying on time of all actors in a distributed system to be perfectly in sync, you already have a bug, leap seconds or not. (unless you are Google Spanner)
For timers within a single system, use monotonic clock of your own cpu.
> Hospitals would just shut off all of their computers during this time to deal with it.
FWIW, there are many things that deal with leap seconds that way too. Too much risk of ending up in a difficult to fix or silently corrupt state, while coming up from a reboot is highly tested and known to work.
The cost of leapseconds is quite significant.
> but if you've ever written code that deeply interacts with time, you'd know how difficult it is to get right.
Good odds that even if someone has that they got it wrong and don't know-- especially when it comes to leapseconds as they're fairly hard to test esp. with distributed systems and infrequent enough that you may not realize the cause even when you've suffered from an issue.
A million problems started when system clocks were changed to follow UTC (as opposed to local time) and then UTC was conflated with Unix time - a fixed monotonic reference, which UTC is not!
Though the ship has sailed, I think it could have been much better if computers were set to follow TAI Time (atomic clock time - unaffected by leap seconds) time than the UTC. UTC is as variable as localtime and should have been treated as such.
If fb wants to - they can (and should) use TAI time for system reference.
This sounds like a sensible solution. If Facebook wants to start using non-UTC time coordination, like TAI, they by all means should try it. They only need to publish their own NTP servers I guess, but that shouldn't be a big problem for an organization of their size.
As far as I can tell, TAI will always be offset from UTC by an integer amount of full seconds, and I guess time coordination between large independent systems is mostly useful just when comparing log timestamps (I would guess almost all sensible software uses already account for much larger clock drifts than the current leap second count of 37, right?)
After adopting TAI, Facebook engineers just need to remember that their log timestamps are offset by N seconds from all the others.
This is actually what the Precision Time Protocol (PTP) does. It's the successor to NTP, so it improves on some of NTP's mistakes. The protocol uses TAI, but also sends the TAI-UTC offset so the computer can display times in UTC.
Why does the time protocol need to send the UTC offset, rather than have the offset be part of system data files, like with timezones? Wouldn't you need the data anyways to translate historical timestamps to UTC?
I think this is the argument NTP makes for not including the offset. TAI can be just another "timezone", so that TZDATA should be to used it to derive it.
But that's backwards. A Stratum 1 NTP usually gets its data from GPS, which HAS the offset (GPS runs TAI). But it only outputs UTC, but not the offset, making other programs compute it from TZDATA. Why is NTP making user programs harder to get the data that IT ALREADY HAS? Because philosophically, NTP is married to UTC (even though NTP is mostly for computers!)
And providing this offset would basically get rid of a large body of people (like the TFA) who wants to CHANGE the definition of UTC, which is a more drastic proposal.
Those are two different problems that require two different solutions:
1. Displaying current time: for that ideally you need the offset directly from the time server because the system timezone data can be out of date in regards to current time.
2. Displaying historical timestamps: for that you use the system timezone file.
PTP and NTP have completely different scopes: PTP requires end-to-end layer 2 support and hateful choice of hardware, so it can only work within a single network; NTP on the other hand was always designed to work across the internet between different organizations, where the network doesn’t help with timekeeping and the organizations don’t work closely with each other.
> Someone should fork the NTP protocol to use TAI instead, and go from there (or at least provide tai offset).
There's a draft of the next version of the NTP protocol (NTPv5) at https://www.ietf.org/archive/id/draft-mlichvar-ntp-ntpv5-04.... which not only has the option of working in TAI, but also has explicit support for "leap second smearing". It also has a field to explicitly provide the TAI offset.
It seems the problem of adopting TAI for computers is because the NTP protocol does not provide the offset. We should add TAI-UTC offset to the NTP protocol.
The ship has not, in fact, sailed: UTC could abandon leap seconds any time. They just need to announce there won't be any more, for the foreseeable future. Along about 2100 they might announce plans for a correction in 2125 or so.
IMHO, leap seconds belong at the timezone layer. I.e. ignore it internally and for things like "seconds since epoch". Adjust at display time.
Timezones are already backed by a database which needs regular updates, including leap seconds would make sense since those are also updated in an unpredictable manner.
For systems that leap seconds actually cause problems on, the solution is simply to use International Atomic Time (TAI) internally, and convert it to UTC when you want to display information to a user.
Every time I see ditching leap seconds come up, they never try to explain why TAI won't work for them, leading me to believe they probably just don't know it exists, nor could they even imagine something like it being invented.
That one's even odder - that's the compromise between the English version, which would be CUT and the French version which would be TUC ... i.e. none of the above.
TUC is a brand of crackers well-known in France, so maybe that’s why they didn’t insist on the French version. And CUT obviously didn’t make the cut. ;)
Coordinated Universal Time in French is Temps Universel Coordonee (give or take an accent). So that should be TUC. I don't think there's any language in which UTC stands for anything. It's a fake acronym.
The problem with English is that you have to plan out the whole noun phrase in your head before you start talking. Not only do the adjectives have to come first, they have to be in the right order. With Romance languages you can just say the noun and then keep tacking on adjectives as they occur to you.
>Oddly, languages either have the exact same ordering as English, or the exact opposite as English. And, nouns in various languages fall in some designated position between the string of adjectives -- in English it's at the end, in Romance languages it's somewhere in the middle, such that most adjectives follow the noun, but certain adjectives precede
Well yeah, the adjective order is actually mostly semantic, and tracks something similar to intensivity. Varying adjective order is not normally a grammatical error per se, it's emphatic (though emphasizing the wrong thing is a pragmatic error).
But in Romance languages you have to plan out very complex sentences. I mean, you don't have to, but it's what people do.
The real answer is that deeply learning grammar as a child makes you think in grammatically correct ways to begin with, which means that when you start vocalizing a sentence, it's already queued up in grammatically correct form or very close to it. This is why we should teach children grammar grammar grammar and almost nothing but grammar, using poetry for memorization, reading to expose them to grammatically-correct texts, and writing to drive grammar home. And some 'rithmetic.
I am a native speaker, which means that I didn't realise that british english isn't actively taught. Like we aren't taught grammar in any particular way (apart from I before E, except after C, which is mostly bollocks, because it depends on the origin of the word. [their for example.])
Basically we are dipped in the language and we either succeed, or in my case dumped in remediation. (I can't spell for shit)
I didn't realise this until I was learning another language as an adult. They were usings terms like "present continuous, reflexives, compound verbs, etc" None of which I knew the practical meaning of.
Teaching a child to read, again you just realise that basically its 5 different languages smeared together, with shit all rules. Syntax, yeah we have some, but no native speak can explain the rules. (we have adjective ordering , but I don't know what it is, I can only tell you if you've got it wrong.)
Seriously, I was reading this article wondering the same thing.
Nanoseconds since X is a fairly unambiguous reference (relativity aside).
Use this for any kind of timestamp or recordkeeping. Convert to UTC (or EST, CST, etc.) as necessary for reference to the solar day.
The only reason not to do this is because you have a million systems that are already running on UTC, and you don't want to do a massive leap second erasure to get back to TAI.
> ... the solution is simply to use International Atomic Time (TAI) internally, and convert it to UTC when you want to display information to a user.
From a software development perspective this seems monstrously more complex than just muddling along with the current situation even with leap seconds.
First, consider the question of "what do unix timestamps mean?" The answer is UTC, except just be broken during the second where there's an extra leap second added or removed, and don't try to represent it. They neither represent TAI nor UTC perfectly, and have no way to encode a leap second, but they are very space efficient to store needing only 8 bytes.
Now, we want to start converting our systems over to TAI, great! To do that we need a format to efficiently store a unix time in a binary representation. For this exercise let's use Jan 1, 1970, and so when we call it we get a value today that's equal to unix time plus 37 (the current offset between TAI & UTC). Awesome, now we need a new function to call it in every single language we use, and then migrate all callsites over to it. Try not to miss any places where someone's passing unix time as an int64 instead of, say, a time_t. If you call into libraries that return timestamps make sure you shim them so that you can convert those timestamps from UTC to TAI.
Now, we have the problem of how to store those int64s. We can't store them in place of our current timestamps, they'll be 37 seconds off. So let's add a field to all databases where timestamps are stored to store the TAI version. Additionally, every RPC is going to need to send along both TAI & UTC during the migration process, so change those too. We can't just ignore cases where we need an integer representation of time, either - those have historically been the places where systems break during leap second changes.
I hope this gets to a little bit of why it would be extremely non-trivial to use TAI in place of UTC right now. If you're storing your time as, say, a string representation with a time zone built in you're right, it's actually generally not that bad, and time zone information is frequently encoded in the string. It's _extremely_ difficult to deal with once you move to a representation of time where the timezone isn't directly encoded in a timestamp.
There are very few systems that care about second-level time that leapseconds don't cause issues for. They are almost universally mishandled by widespread systems, so much so that we even get multi-million dollar scale internet disruptions due to leapseconds when there hasn't even been a leapsecond.
I doubt anyone talking about the elimination of the leapsecond is unaware of TAI but TAI is not readily available on general purpose computers (and, increasingly, UTC is being silently substituted for leap-smeared UTC). And for specialized systems attempts to make pockets of TAI break down when they have to talk to the outside world (and have consistent times with it) and/or due to hardcoded leapsecond tables in software.
The bigger problem is that UTC (and TAI) is defined in a gravity well so it's not going to be very useful in the long run. GPS has to correct its clocks to keep track of what we slow Cesium/Rubidium down to on the surface, and Voyager's clock is going even faster. We clearly want an Earth-centric time standard for wall clocks and that is UTC. The Earth is not a precision time-piece so we will always have to adjust our wall clocks to its rotation. Realistically, we should probably be deriving a time standard where every day has a slightly different length and we record the timestamps of the beginning of each day relative to a universal monotonic clock in a log (with rollups to years, centuries, etc.) that we keep around as long as anyone cares exactly how many Cesium vibrations have happened since $whence.
If we want to actually solve the problem then let's switch to an interstellar time standard in a rest frame relative to the CMBR as far outside of gravity wells as possible and make that the universal monotonically increasing standard. Then computers can run on that time standard and UTC and friends can be derivatives.
I'm not sure it matters. To synchronize, you'll have to make corrections either way, and over sufficiently large scales, signal propagation delays are going to be quite large.
Here my physics knowledge gets a little sketchy, but if we have an accurate clock broadcasting on a known frequency somewhere far away we should be able to at least measure the drift between it and a local clock to arbitrary precision. With ~zero drift we can measure the distance and relative velocity very accurately with round-trip timing and Doppler measurements, and from that measure the clock offset as accurately as we can measure the distance. I think, but could be wrong, that we'd always be measuring the spacetime interval, not the euclidean distance in space, but that is probably what we actually want once we start caring about relativistic timekeeping.
> let's switch to an interstellar time standard in a rest frame relative to the CMBR as far outside of gravity wells as possible
This won't work: since galaxies aren't static, and because the universe expands, the point with the highest gravitational potential ("as far outside of gravity wells as possible") will both move w.r.t. the CMBR and have a gravitional potential that changes over time.
Maybe I'm making a bad assumption that intergalactic space is so flat that pretty much any region of it will do as a reference. Since we can't reach those regions yet we'd still be approximating it with our slower clocks, but it seems like it's at least feasible.
Galactic groups are gravitationally bound enough that they’ll stay together through the expansion of the universe. Would want to find an area that is particularly void of galactic influence maybe?
Your proposal is to make the time Standard of billions of people not match what they experience, on behalf of a few space probes, none of which will use it.
Meta don't want leap seconds because leap seconds make distributed system cluster synchronization tricky, because that's the only case where an extra second here or there actually matters.
Across all the devices in my house that have a clock in them, the time drift is a little over an hour and it doesn't make the slightest bit of difference to me: internet connected computers being the most accurate.
Between individual computers, thanks to filesystem semantics, drifts of up to 2 seconds are expected and generally considered "identical" - it certainly doesn't matter for file sync applications.
So either we want to build a time standard that can be transformed in a sensible way to all the others which are useful - in which case something which works for interstellar timekeeping would be a sensible step, given that relativistic issues crop up even in Earth orbit, or we're building a time system "for humans" in which case everything we have now is fine, and will by definition be messy because time and timezones change all the time.
That is absolutely not the only case where an extra second here or there matters.
It's just for distributed systems the OTHER ways of dealing with the problems leapseconds create (e.g. using a local monotone clock) aren't available. But even where they are available leapseconds still create issues because they're extremely difficult to test and are often handled somewhat incorrectly.
UTC without leapseconds would in no way be less "for humans". After 4000 years of drift the effect on the solar noon would be about the same as you get driving to the next state over.
Except as I noted up thread we've already got "UTC without leap seconds" - it's UNIX epoch time which is defined to ignore leap seconds.
Leap seconds are still seconds so even with GPS sync, if all you're doing is tracking 1000ms increments then we have a format already which doesn't have them.
Unless I am misunderstanding what you are writing, you're mistaken about unix time, in practice.
In unix time there are 86400 "seconds" per day since the epoch. On days when there is a leapsecond the timestamp of the leapsecond is given out for two (TAI) seconds.
A result is that unix time stays in sync with UTC and the difference between them doesn't change.
The belief that conventional unix time is somehow leapsecond free is a common source of leapsecond handling bugs. :( It results from misleading standards text which states that it doesn't have leapseconds, which it technically doesn't-- instead leaves the second undefined, which implementations distort to make unix time match UTC.
If your goal is to measure accurate durations, synchronize distributed systems, or point telescopes-- unix time will not solve any of your leap second issues.
Thanks for the clarification, but I think my underlying point still stands: ignore leap seconds - invent a time standard without them, which in practice would probably be Unix-time-sans-leap-things, and calibrate off against that.
It's plain weird to rewrite the world which doesn't actually care about leap seconds for use-cases which don't work in normal human reaction or processing times. 1000ms is a value only relevant to high precision applications, which are perfectly fine not being tied to a precise date or solar rotation or anything.
This feels like a programmers without science training issue: all models are models and you choose the one useful for your purpose. It's particularly galling coming from Meta who are large enough to just do this, write the code, and submit a standard for consideration by the tech-industry.
Your "feels" have no influence on any of the firmware in millions of devices that are coded the way they are coded, and cannot be changed, and fail to synchronize with the others that do change in response to a leap second announcement. Those devices do not respond to your sense of fitness. They just fail, and take along everything that has to synchronize with them.
Except everybody is already using UTC, and will not change from UTC to "Unix epoch time" on your say-so. Or to TAI or any other crack-brained system you can think of from your armchair, including all the hardware that cannot be changed without throwing it away and buying new.
All we need to do is simply choose not to announce that all the software in the world that (might have) "got leap seconds wrong" but still has to talk to the other half that (might have) "got leap seconds wrong" will be officially broken, this year. Or next year. Etc.
The TAI second is defined relative to a particular gravitational potential. Adapting to another known one is just a unit change. (if you don't know then nothing can help you).
The difference between potential already need to get handled on earth. Esp. since the NIST labs in boulder are at about 5400 feet.
Is there a single change that can ever be proposed that would be considered worth it? I can only conclude that status quo bias is very strong among people. With this in mind, I can only conclude that Mark Zuckerburg is some kind of organizational genius with both his "move fast and break things" and his "move fast with stable infra" lines.
Can we not just fix our systems to run in TAI or GPS time, and convert to UTC (or the user's local timezone) when displaying timestamps, instead of causing civil time to drift off indefinitely? I thought these were the best engineers in the world, go fix the computers then!
Humans want noon to be when the sun is overhead, and midnight to be the middle of the night. Almost nobody cares about sub-second accuracy or monotonic time. Track it that way internally if you like, but humans want time to correlate to what they see out the window.
That is what everybody ends up doing, in practice.
It is exactly the problem. Why should every software system everywhere have its own complicated, unpredictable, error-prone fudge that benefits literally nobody?
If utc is causing problems with your calculations due to leap seconds than you should be using Unix time to do the calculations and then translating that to a human readable format.
Imo society needs three distinct time counting systems.
1. Linux time. Essentially a universal addressing system for the measure of time in a agreed upon reference point (Earth’s surface). This should be the standard for science/computation, with the need for language to describe time dilation when comparing two reference points. Unix time doesn’t have leap seconds, or the concept of days.
2. UTC aka civil time. Things such as the orbit of the sun and the rotation of the earth aren’t in constant speed and don’t divide evenly with each other. UTC deals with short term variability with leap days and leap seconds. This is so every January 6th the earth is roughly in the same spot relative to the sun, and every 5pm the earth is in roughly the same part of its rotation. This is important because these things drift on human scale timelines. This calendar should be used for daily life, business, etc.
3. A purely astronomic calendar. A calendar that defines time by astronomic events. For example, defining a day as one rotation of Earth and not as a number of times an atom vibrates. This should be used so we can discuss astronomical events such as “A Martian year” or a “Saturn Day” and provide some meaning. This is the basics that should be taught to elementary school children to establish the cultural meaning of a day or a year and to provide some basic learnings of nature.
If we used a unix-time-including-leap-seconds instead then the date/time conversion functions would need to have a little extra smarts (a table of leap seconds in addition to a timezone database) but most of the leap second related problems would not exist.
(We already deal just fine with months having variable numbers of days. Minutes having variable numbers of seconds is obviously awkwardly rare from a testing point of view, but not fundamentally more difficult to get correct.)
The fundamental difference is that we can predict well in advance how many days will be in a given month, and the rules for calculating that number can be implemented with a short lookup table and a few modulo operations.
The lookup table for past leap seconds, however, is already longer than 12 entries, and there is no way of calculating the length of all future minutes.
On the other hand, the problem may be simpler than keeping track of changes to timezone definitions, since there are hundreds of jurisdictions that can unilaterally change those.
610 comments
[ 4.6 ms ] story [ 483 ms ] threadI would have loved to read more justification about _why_ Meta thinks we no longer need the leap second beyond calling it a community push. They did a great job of complaining about how hard it is to solve from a technical perspective, and then explained how they solved it. Is the only problem really that Meta doesn't know how to test a negative leap second?
> This periodic adjustment mainly benefits scientists and astronomers as it allows them to observe celestial bodies using UTC for most purposes. If there were no UTC correction, then adjustments would have to be made to the legacy equipment and software that synchronize to UTC for astronomical observations.
> While the leap second might have been an acceptable solution in 1972, when it made both the scientific community and the telecom industry happy, these days UTC is equally bad for both digital applications and scientists, who often choose TAI or UT1 instead.
The claim is that the benefits accrue primarily to a community whose relative importance is minuscule compared to the broader software world in 2022. The tradeoff was made in 1972, when astronomers etc represented a vastly larger proportion of software.
https://www.cl.cam.ac.uk/~mgk25/time/leap/
Time in the real world can use leap hours, the next of which will be in approximately 3000 years.
This is all quite hypothetical as it’s hard to predict whether anything like our current technological civilization will exist thousands of years from now, but even if it does, a simple mechanism exists to avoid problems (just have each jurisdiction change their local time when they decide they want to).
I can’t see any downsides for literally anyone from this proposal, other than the insignificant downside to the British that they will lose the prestige of being the place that global standard time is based on.
> lose the prestige of being the place that global standard time is based on.
You joke, but that's actually a source of some of the opposition. :(
It infuriates me that the BBC World Service insists on announcing the time as "<something> GMT", pronounced in a smug tone of voice. The GMT timescale no longer exists; nobody broadcasts it. What the announcers are broadcasting is the BBC's ignorance. I find it embarrassing and jingoistic.
They've also adopted an idiosyncratic way of pronouncing the time itself: "The time is Four, GMT". Everyone else says "Four O'clock", or "four hundred hours" or "four AM". The Beeb are almost completely immune to complaints; they've outsourced their complaints department, and the contractor's brief is to make sure no complaints reach programme makers.
Time may change forwards and backwards, because my computer clock may be fast or slow. The same logic to correct for leap seconds, can be used if my computer is 2 sec fast.
And your code had better handle it, and the os, libraries, it really is only hard ), if you have to support 1000s of novice devs.
Honestly, this issue screams education problem. "Time is a mess" should be taught alongside buffer overflow attacks and networking theory (in fact, networking theory is a great place to teach "time is a mess," because you can roll it in alongside ideas like "simultaneous action is a lie" and "clocks are always wrong anyway").
Already decades ago many have proposed to use only TAI internally in computers, instead of UTC, which is not a time.
UTC should have always been used only to compute the local times, together with the time zones, only for human interfaces.
There have been for decades libraries for using TAI instead of UTC, and even versions of Linux or *BSD kernels patched to do time keeping in TAI, not in UTC, eliminating all problems with the leap seconds.
Unfortunately the use of TAI has remained a niche, but that was the right solution.
If you want to use real-world time, you have to make sure it stays in sync with the real world. Switching to something which is close-but-not-quite-correct will cause even more issues than we are currently having with leap seconds. Can't deal with that? Well, just use the Unix timestamp like the rest of us?
Currently our calendar goes off by one day in 3236 years. If the history is calendars is indicative, in about 10,000 more years we may change our calendar. (Or, being multi-planetary by then, maybe we'll consider it a quaint relic of our origin.)
Our clocks predict astronomical time of day to less than a minute for a human lifetime. And both DST and timezones demonstrate that we're happy to live with the clock and Sun disagreeing by an hour or more.
My position is that both are currently good enough for the next couple of thousand years. And we can let our distant descendants sort it out when the time comes.
It’s more likely that every planet will have its own calendar and you’d have to do the conversions and translations. That’s what scientists do with Mars time. Thanks to relativity, time at point A is not the same as time at point B, and whether they stay in sync for you depends on how you get from A to B.
While "now" can vary according to the time it takes to get from A to B, all observers can work out what "now is according to the reference frame of the distant stars". On a mere interplanetary scale, this idea is amazingly precise. We might not agree on how much time passed (this has already mattered for GPS satellites), but for all practical purposes "now" is perfectly meaningful.
It's not that we'll never need another leap second; we could add ten, negative ten, or zero in the next 25 years and Earth won't care. Who will care are humans, who may get a bit annoyed when the sun starts setting in equatorial latitudes at 3PM.
There are some good arguments for keeping leap seconds, but I don't think research astronomy is really one (it might be more useful for amateurs), particularly on ~100 year timescales where you don't expect things to slip that much. I think this sentiment is shared by most of my peers, particularly those who actually have to implement data acquisition and analysis pipelines!
After all, there are still pieces of the original Bell organization and infrastructure around in active use, just with the names on the business cards and buildings changed. I don't think someone 50 years ago could have predicted which parts would still be around and which long gone.
Why not just agitate for a move to French Revolutionary Decimal Time as well?
even with the best and brightest engineers there is a non-trivial probability that someone will make an assumption that is invalid based on their understanding of what can happen (ex. leap seconds never go negative!) or the library their using (this ensures monotonic time!) that could lead to disastrous results. and especially at meta scale, that probability is no longer "will someone make this mistake in our code?" but is "how many times will people make this mistake in our code?", so systemic solutions that eliminate this as a class of problem an individual can create is something we should consider.
You mean some influencer's timeline could get messed up? The horror!
there are also all the other companies out there who do not have the platform that meta has that can also hit the same issues. i'm sure some of them have products you wouldn't be so glib about.
Only facebook here is the one suggesting we should change things, so who is using facebook as critical infra and what is your definition of "critical" here.
If a 21 year old grad can move 200 terabytes of historical data 15 years ago what are the best and brightest at FB doing with their lives?
This is one of those cases.
* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...
Of course there's a whole lot of other userland code besides ntpd.
Better would be half of everything not breaking every 15 - 30 months.
This article details some of the problems: https://www.ucolick.org/~sla/leapsecs/dutc.html
(You may want to scroll down to "Implementing the plan outlined at Torino".)
If we end leap seconds, it doesn't take long - only until 2028 - until "midnight" is sufficiently far from "the middle of the night" that you will have to consider the legal issues caused by events that happen just before or after 0000 hours.
By 2055, the "minute" displayed on a clock may be incorrect, which again may cause issues with legal timestamps.
And by 2083, sundials are measurably wrong.
All because programmers wanted to save some lines of code.
Astronomy already ignores leap seconds in the same way that modern finance ignores half-crowns and shillings.
To explain a bit further: UT1 tracks the Earth's rotation relative to distant quasars and is thus directly the correct clock/reference to use for pointing telescopes. However it doesn't advance at a nice and stable constant frequency, but something that slowly changes over time (and can shift by strong earthquakes) and thus we approximate it with UTC, which runs at a nice constant frequency, but needs occasional correction to match up with Earth's rotation.
Changing to TAI means you are different from everybody else, and still have to fool with leap seconds to know what everybody else is using. Worst of all worlds.
(Except Google smearing, which is even worse than that.)
Yes, the actual problem exists, and ignoring/discarding reality (i.e. the "science" in computer science) will just cause further problems. If you and your modern stack of code can't handle the leap second, it's simply not production code.
I mean this is the whole contention. Meta's claiming this isn't actually a problem worth solving.
Sundials being "measurably" wrong become an issue at long spans. For example, no one wants solar noon to be at 10AM -- but that takes a while.
Solar noon in Spain is after 2PM already.
I agree, but I'm also - sad to say - less than surprised to find engineers at a Big Tech firm taking a high-handed, not to mention narrow and ill-informed, approach over the issue and trying to impose their will on a global scale. My worry here is that, Meta being Meta, they carry quite a lot of influence and may actually gain some traction.
EDIT: I'll add a bit more colour here. At the core of our platform we manage a database containing billions of legacy timestamped records (or events, if you prefer), adding more and more every day. Without even giving it a great deal of thought I guarantee you that this proposal will cause us more problems that it solves and will distract us from making more valuable investments of time and effort that would benefit our business should it be implemented. Sure, we can no doubt fix all these problems, but we've got better things to do. I imagine that many other businesses would be similarly affected and would take a similar view.
I wholeheartedly oppose it.
Big Tech companies/Anti Big Tech lobbyists massively oversimplify in their pitch to influential people to deregulate/overregulate certain areas. In both cases they end up making poor decisions for the general case both end up making the average case worse for everyone except themselves. It's about creating a market where none need exist. Facebook doesn't need to care about time really. It's not remotely important to their business.
I've built and worked on platforms with sub microsecond measuring requirements and this stuff didn't bother me. This is idle bad money finding work for itself at the expense of everyone else.
Disclosure: I am/was an early investor in facebook in 2012. Mark is turning it all to dirt because he's run out of ideas
Right back atcha.
We have three alternative time systems and a big bag of issues with each of them, but you think the extremely mundane argument that we should prefer one bag represents nauseating arrogance because you think that your favorite bag -- a different one -- is obviously correct? Come on. Do better. Be civil.
That is effectively proposing the deletion of the most commonly used time system of the three primary time systems from existence and forcing everybody and all existing systems that use it to convert to what is effectively TAI.
That is not mundane. Mundane is arguing that everybody should use TAI. Arrogant is arguing that we should force everyone to do it by redefining their dependencies under them.
Arrogant is imposing a big nuisance on everyone every year or two. It is not arrogant to ask for a nuisance affecting millions to be dropped.
If there was a scheme that fixed only the wrong usages, that would be fine. But, it is frankly absurd that we should even consider breaking carefully designed programs correctly using their dependencies to fix programs incorrectly using their dependencies especially when it is trivial for the wrong usages to be fixed manually.
Not announcing any more leap seconds will break exactly nothing.
People using the wrong dependency should fix their system to use the right dependency. They should not campaign to steal the name and replace it, that is absurd.
The only people who care or need to do not use UTC. They use TAI, and a separate continuous log of fractional seconds.
UTC has one role, and that is Standard worldwide civil time. Telling people who need Standard civil time to use TAI makes everything strictly worse: not only do you then not match most of the world, but you still have to track irregular, unpredictable corrections to be able to sync with everybody else.
That is what is proposed to be fixed and that you are arguing against for reasons you don't know or, apparently, care about.
Switching civil time to TAI would break everything, most of which cannot be fixed. Random breakage is the problem. More breakage would be strictly worse.
That's just... completely incorrect and totally false? Have you ever even worked for a business? Have you ever read how time libraries are actually written?
Please, go read the Python `datetime` library: https://github.com/python/cpython/blob/0fe645d6fd22a6f57e777... which is used to calculate a UTC timestamp: https://github.com/python/cpython/blob/0fe645d6fd22a6f57e777...
It is literally built on the exact assumption that 0 means January 1, 1970 and that right now is (number of seconds in a day) x (number of days since Jan 1 1970). If we stop adjusting UTC, then by this time next year UTC will be one second out of date with our wall-clock times, and calling `datetime.now().isoformat()` will give us a timestamp that's 1 second off from the wall-time of a user. At one-second past midnight on the 20th of the month, your computer will incorrectly be spitting out timestamps saying it's exactly midnight of the 19th. That's what you might call a major breaking change.
Says something about how Facebook sees itself, I guess.
Leap seconds are exactly the "screwing around" you criticize.
Neither do I in day to day life. But I do have to care about it when I or members of my team write code, or store and retrieve data to and from a database, or work across multiple timezones, because it can be critically important to unambiguously know whether something happened on one day or the next.
The reality is there aren't any nice, elegant solutions to this problem. Leap seconds aren't a nice solution. Meta's proposal isn't a nice solution. I don't necessarily even think it's worse than leap seconds, but it's certainly not substantially better. The key point is it's a change and one which, in my view, won't deliver enough value for everybody (beyond just Meta) to justify the level of disruption it will certainly cause if implemented.
Let's paint a picture based on actual code I've actually seen in the real world. If you ignore the leap second but keep using UTC, then in about 5 years, UTC will differ from wall clock by about 5 seconds. So if, in some software used for, I don't know maybe billing customers, someone was calculating day boundaries by doing modulo division of UTC by the number of seconds in a day (I've seen it), then in 5 years we've got a 5 second discrepancy in the number of API calls made by customer X when comparing what the software says to what the customer measured. Customers don't like this, accountants and lawyers REALLY don't like this, and us engineers will have the wonderful experience of telling them all
> "this code used to be valid until some boneheaded engineers at Facebook convinced a ton of other engineers to break the agreed upon standard about what it means to measure time in this way, and now things that used to work fine need to be patched because we've got a Y2K EVERY DAY!"
Oops, I guess ignoring wall clock time might be something other human people care about after all.
I'm not following here. What defines "legal timestamps" in our current system? I'm unaware of any laws in the US that uses the actual position of the sun to determine the time.
"Noon" when the sun is at the highest point, can vary over an hour across a timezone.
this is "solar noon" - just "noon" denotes 12:00 on the clock [1]
[1]https://www.bsu.edu/academics/centersandinstitutes/ceres/hel...
Shifting the timezone by a couple seconds does not prevent or hinder cataloguing events in any way whatsoever, certainly not more than switching to daylight savings time does or the mere existence of timezones, which may easily be half an hour or even more off from the solar time - the offsets we use for time are effectively arbitrary already, and adjusting the arbitrary choice of the offset by some seconds is not a fundamental difference. Event timestamps already map to different days depending on different timezones, you do need to know which timezone your clock is using, of course, but you already need to do that.
> This could affect everything from university applications to boating licenses to social security.
Last time I looked, a boating license required you to be a certain age. Dec 31 and Jan 1 are still just as far apart as July 6 and July 7.
I'm not sure what you're getting at here. If we stopped introducing leap seconds, then why would the legal world still care about them?
_Some_ legal uses of time are probably concerned with this, but I'd think it's a pretty small minority.
Or even have legislation to agree on that and set single law.
By precedent, UTC seems the logical choice for the one time system.
Telling people to use TAI is telling them to have a different time from everybody else. The whole point of civil time is specifically that other people use it. Using TAI does not free anybody, because anytime you need to interact with outside, you are back in the nightmare.
I've tried to build systems using TAI they break down because: At some point you have to interact with something that doesn't use TAI and that fully reintroduces all the leap second issues, and because a lot of third party software has leap second handling, so the wheels fall off when you update some component and its embedded list of historical leapseconds now changes its behavior. Similarly, sometimes UTC time is all that's available and without the leap second data you can't back them out to get TAI.
And with leapsmear the challenges of backing out to TAI have increase substantially.
And the best way to do that, is to simply define UTC, to be TAI. Thats the point.
This isn't just about lines of missing code. This is about forcing subterranean or submerged computers to surface. This is about out of sync clocks across information propagation networks across planets. This is about real lives that are ruined because time stamps didn't quite line up, causing delays, deaths, and needless headaches.
It doesn't need to be this way. We could just accept a minute of the clock being off from "true" midnight, which doesn't even make sense to me given that few people are right at the astronomic point where midnight is "true" midnight for their timezone. Heck, China is one big giant timezone so who is this actually for, really? The people that care about sundials? Most people don't even grow their own food.
We're no longer a sun-driven economy. Well coordinated timekeeping across devices that may not always be able to transfer data is far, far more important. If it's sufficiently wrong by the year 3422 then we'll deal with the fifteen minutes of annoyance then. This is a crazy premature optimization.
How do you have a well coordinated clock without being able to get four bits [1] per year of leap second data? It's hard to keep within one second of a time standard over 6 months or a year without communication.
[1] bit 0: was there a leap second in the most recent period, bit 1: was it positive or negative; bit 2: will there be a leap second at the end of the current period, bit 3: will it be positive or negative. Bike shed my fictious encoding if you like, but it's good enough. Use a whole 8-bits, go wild.
For “midnight” being far from “the middle of the night”, that’s already a reality for many Chinese living far enough from Beijing, or god forbid regions where “night” doesn’t mean much for half of the year.
For all intents and purposes, if a formal definition of time isn’t practical people come up with their own ways.
And then there is continental shifting... Which we also don't account for...
A few seconds or few minutes really don't make that much difference for average person.
Since the article was published we've gone from positive leap seconds every so often to looking like we may get the first ever negative leap second: https://upload.wikimedia.org/wikipedia/commons/f/fb/Leapseco...
Which means the article's estimates on how long it will be until we're off by a given amount of time are very much obsolete.
[1] https://web.archive.org/web/20030801000000*/https://www.ucol...
Some people: astronomers and orbital mechanicos are obliged to care about sidereal time, regardless. Making me deal with it too is pure tax with exactly zero benefit.
No, it's because programmers don't want basic timekeeping in all devices involve the worst issues of managing a distributed system.
The worst case scenario is things are different.
Timestamps are exactly what we define them to be. There is no correct and incorrect.
One option is to have a system with arbitrary unpredictable leaps to keep it synchronized to within 1 second of the mean solar time over Greenwich, England. Every computer system that has to deal with time accurately needs a lookup table for leap seconds that is occasionally amended, with only a couple months warning in advance.
Another option is to just let the clock run at a constant rate. In this case only astronomers have to keep track of the difference between solar time and clock time (which they already do anyway).
The fact that the difference will increase to an hour after several hundred years is utterly irrelevant. If people in the future care, they can simply adjust the timezone definitions to compensate, since timezones are already adjusted all the time.
Yes. Problems with delay time going negative usually come from not using CLOCK_MONOTONIC for delay time. CLOCK_MONOTONIC is usually just the time since system startup. It comes from QNX (which, being hard real time, had to deal with this first), made it into the POSIX spec around 1996, and is now available on all major OSs. But there's still software that uses time of day where CLOCK_MONOTINIC is needed.
Then there's the smoothing approach. This document described Facebook's smoothing approach, which has a different smoothing period than Google uses.
* Facebook/Meta: "We smear the leap second throughout 17 hours, starting at 00:00:00 UTC based on the time zone data (tzdata) package content." This is puzzling. What does the time zone package have to do with UTC?
* Google: 24-hour linear smear from noon to noon UTC.[1]
* AWS: Follows Google.
* US power grid: Starts at midnight UTC and takes a few hours while all the rotating machinery takes 60 extra turns to catch up.
Not sure what telecom is doing.
[1] https://developers.google.com/time/smear
The IANA TZ database includes information about leap seconds, and even supports the concept of "right" time zones in which the leap seconds are counted in the Unix timestamps. (Which violates the unix spec, and may cause problems with code that assumes it can do path like `1 day= 24*60*60`, but on the other hand, things like DST already make that unsafe).
It is mostly likely simply the case that they are using the leap second data from the time-zone database as a convenient source of this data.
Why 17 hours instead of 12 or 24? Something to do with 17 being a prime number or some convenient divisor?
> In about 600 years TI will be ahead of UT1 by half an hour, and in about 1000 years the difference will be a full hour.
That's nothing. Time zones alone already create significantly larger errors. Belgrade and Sevilla share a time zone, but the solar meridian ("noon" on a sundial) is 12:44 in Belgrade and 14:30 in Sevilla. Obviously, the same error is present in the astronomical "middle of the night". This does not, in fact, create "legal issues" for Serbs or Spaniards.
In 600-1000 years, around the time that it would actually matter, we're going to have to reform the time system anyway to account for relativistic drift between the surface of the Earth and human settlements elsewhere in the solar system.
You FAR overstate the impact on civil society of failing to change it by a second every so often.
Ironically even astronomers, who leap seconds were originally for, don't benefit because they need to know the Earth's rotation accurately to subsecond levels.
Honestly from my perspective, 3am is the middle of the night (night-morning-afternoon-evening starts at 0-6-12-18 for me) and somewhere between 4 and 5 most people are probably asleep and the date change should occur. I can't count how often I've heard people clarify what 'tomorrow' means when the word is spoken after "midnight" but before going to sleep.
But yeah gotta pick something for the date change, it won't be worth the cost of change now. If we do end up ever switching to something like decimal time, this should be on the todo list though.
And I know "midnight" is historically supposed to be about the sun being the furthest from its zenith rather than in the middle between when you go to sleep and get up, however that occurs somewhere around 1am here (01:41 at its extreme, from July 17 till August 5th). If that's not enough to warrant a redefinition, 27 seconds accumulated since we started counting leap seconds are also not enough to warrant an update yet (following Facebook's logic here).
All these arguments based on sun position make no sense in a world where people already live in places where the sun literally never sets or never rises for months, and people already live in time zones offset many, many hours from "correct" time. The sky doesn't fall!
That article is ridiculous.
* "Most telescope pointing systems fail" (by 2027) (with 5s deviation from earth rotation). Pointing systems cannot blindly rely on UTC anyway, since (a) even with leap seconds UTC is up to 1 second off earth's rotation, and (b) pointing a telescope depends on where the telescope is on earth, so some offset must be added to UTC by some human.
* Hypothesized legal issues... give me a break.
It would be much less trouble for humanity to deal with this once every 100 years or so.
I can't follow your logic here. In any relevant context midnight has a definition, typically UTC midnight in the applicable timezone. Eliminating leap-seconds would make the instant midnight occurs less ambiguous in 2028, because precise timing with leap-seconds is strictly harder than without. (and one can independently realize a time that closely follows TAI but one cannot independently realize UT1 without a VLBI radio telescope array, and one can't realize UT1-TAI without a datafeed because the decisions are subjective).
This isn't just a question of 'some lines of code'. Leapseconds cause widespread disruptions even when they don't occur, they cause security vulnerabilities (and slower and less secure systems because they make synchronization unreliable). People are widely deploying "leap smeared" NTP servers to try to prevent some of the worst synchronization faults, but doing so makes it impractical to back out leap seconds to derive TAI (or a more accurate TT) from the system's UTC, particularly because systems don't know if they're leapsmeared or not (and different smear sources use different smearing parameters).
Also, why were non-linear smears thought to be desirable? Googling just turns up hand-wavy phrases like "easier on clients".
I found more details and motivation in this article: https://developers.redhat.com/blog/2015/06/01/five-different...
> current non-smear time
This is the server that keeps that time! ;)
But IMO, the time keeping device should be a separate hardware module with battery backup that is never is restarted.
The computer should not be keeping time to begin with.
My only guess is that because smearing takes place at Stratum 2, if the network partitions part of the NTP servers downstream (Stratum 3+), they'll have an offset as large as T/(17 x 3600) (T being the partition duration in seconds). Yet I guess it must be something else for I cannot see why that won't be tolerable.
More generally AFAIK the NTP RFC does not include smearing period, which is why the best practices are to only use smearing in a well controlled environment rather than on public facing NTP networks, but why is this not something that can be fixed? I'm not sure.
And, maybe, don't run sub-second benchmarks with a wallclock.
Of course it was Google who picked the worst of all possible choices.
You might call the biggest earth-moving company in the world and see if they will give you a quote for that.
This feels very can-kicky, even if the can can be kicked a thousand years down the road. I don't think more can-kicking is really the best solution.
I've been on the front lines of adapting code for a novel timezone change. It wasn't pretty.
The hubris of “we’d rather not do this, so let’s make the entire rest of the world deal with it instead” is impressive.
We do lots of things that are hard because doing them right is often more important than doing them easily. Switching from ASCII from UTF-8 was a pain, but we did it. Software upgrades are a pain. Security infrastructure is a pain. Timezones are OMG such a pain. But in all those cases, we collectively said “welp, guess we’ve gotta do it”.
And what Facebook notably didn’t propose was a way to actually make this happen. Who’s going to project manage the global coordinated effort to migrate the planet to Facebook Time? That sounds like much more work than them just fixing their time handling.
I agree that we don't just need to do something because fb wants to do it, but it might actually be worth having a discussion over.
But I don’t feel like this rose to the level of an actual proposal. It was very short to assert a claim with such wide-reaching implications as “we should start ignoring leap seconds”. As such, I don’t think it calls for an in-depth rebuttal.
Consider:
Proposer: “It’s time to leave Unicode in the past. It requires us to update every part of our system to deal with UTF-8 strings instead of much simpler ASCII, and we’re spending a lot of resources. Because it’s so hard and expensive, we should all use well-tested ASCII code. People who want to interoperate with our system can just rename themselves to use the Latin-1 alphabet.”
Everyone else: “No.”
Yes, it is hard, and people have spent a lot of, ahem, time and money to figure out how to manage this at scale. But there are real-world-tested approaches to dealing with the issue, and I firmly believe it’s better to work out and coordinate on the remaining rough edges than to throw the whole thing away to make a handful of engineers’ jobs easier.
"A small number of countries however, including Russia and the United Kingdom, want to keep the leap second."
https://www.nature.com/articles/nature.2015.18855
UK used to decide on which date to switch to and from "summer time" every year. "The admiralty will take up the question in coming weeks."
Source: I managed to make a transition from UTC to TAI in a broker trader in 2009 when I was fresh out university.
The world is messy, life is messy, and so is everything else. If that’s too much for poor programmers, they need to find another job.
I obviously meant “re-engineering”, but “de-engineering” works as well, in this case…
"Let's just kick the can down the road" isn't solving anything.
> "As an industry, we bump into problems whenever a leap second is introduced."
Their suggested solution is:
> "As engineers at Meta, we are supporting a larger community push to stop the future introduction of leap seconds and remain at the current level of 27, which we believe will be enough for the next millennium."
Most folks are rightly pointing out that there are many other solutions that we could introduce, which wouldn't have the downsides of UTC drifting away from our wall-clock time. Facebook didn't even discuss those solutions though.
An example possible other solution: programmers (especially programmers at Facebook) should stop using UTC and should instead use TAI (which is literally UTC but without leap seconds). Indeed, using UTC time as anything other than a wallclock time should trend towards the norm. Even though this is a clear tru-ism, seeing it adopted would be way harder (due to language inertia and habits) compared with just changing the standard (nevermind that changing the standard would break a ton of logic built around expectations like "midnight UTC falls on an integer multiple of 86400").
The purpose here is for things to get better, not worse.
The idea that this problem is so hard that users have to be inconvenienced to the point that reality is ignored is a bit strange to me.
Only TAI is a time.
Already decades ago, some programmers have argued that internally all computers and their software should use only TAI, which is a time, so it behaves as expected, while UTC must be used exactly like the local times and the time zones, only at the interfaces with humans.
If that proposal would have been adopted, there would not have been now any discussion about the leap second.
The only reason for the existence of UTC is to keep dUT1, i.e. UT1 - UTC, under 1 second.
If the leap second is eliminated, then dUT1 will grow over 1 second, so there are other cohorts of hardware devices and software applications that must be updated in order to no longer rely on the assumption that dUT1 is less than 1 second.
Anything that has any relationship with astronomy, e.g. for observations or for navigation, relies on computing UT1 (i.e. the angle between the mean Sun and Earth) from time, so it would have to be updated.
Changing the definition of UTC would make it completely redundant, Instead of giving up to add leap seconds to UTC, it would be much better to make a final leap of a half of minute and have TAI = UTC after the date of the big leap.
Having 2 identical times with an arbitrary offset between them would just add needless complications to all time-related software, forever.
Could you elaborate on what you mean? What is UTC if not a time? Like, datetimes vs time?
Even if Unix time was based on TAI, you'd still need leap seconds in order to resolve the correct local time (which is based of even-minute offsets of UTC). Maybe it's easier to deal with in calculation post-hoc vs smearing on the day of, but that handful-of-accruing-seconds will always be there.
The mean Sun is a fictitious Sun with a motion that is averaged in comparison to the real Sun.
UTC is the UT1 angle rounded to a multiple of 1/21600 of a right angle, i.e. the angle corresponding to 1 second of time for something that completes a circle in 1 day.
Because of this rounding, actually a truncation, UT1 = UTC + dUT1, where dUT1 is between 0 and 1 "seconds".
Even if UT1, dUT1 and UTC are expressed in "seconds", these "seconds" are not the unit of time, but like I have said, such a "second" is 1/21600 of a right angle or pi/43200 radian.
Both UT1 and UTC are angles that approximate the longitude of the projection of the Sun on Earth, with various accuracies.
Because the rotation of the Earth, which causes most of the apparent motion of the Sun, is almost uniform, the angle of rotation is almost proportional with the time, so the angle UTC is almost proportional with the time, i.e. with TAI.
Because of the way how the "second" angle used for UT1/UTC is defined, the approximate proportionality becomes an approximate equality of TAI with UTC, but because the equality is only approximate, there is an increasing offset between them.
In the ancient times, the people did not care much about time, but only about the angle of the Sun, which determined when it was light or dark, hot or cold, enabling or preventing various activities.
In modern times with artificial lighting and heating and with many activities that proceed at predictable rates, time has become much more important than the angle of the Sun.
In any case, in all contexts we must be aware that the angle of the Sun and the time are not the same thing, even if they are almost proportional, i.e. almost equal after a change of the measurement unit.
That's like saying a watch or even an atomic clock doesn't measure time, it measures oscillations. It's being pedantic to the point of obtuse.
UTC has exactly one purpose: to be a common reference for everybody else. Making it not mess up everybody else, every year, is obviously the better choice.
You may stop beating your spouse now, and it will be purely an improvement.
Having made the mistake 27 times already does not justify making it even a single occasion more, never mind forever.
Reaction: let's stop using the system we have some practice at doing, and instead open up the question again, but really just have big tech corporations dictate to the world that we need to do something else.
Choosing not to impose a hassle and source of bugs on millions of people every year or two is obviously correct.
Anyone who wants to use what astronomers use will still be free to do that, without bothering literally everybody else.
https://www.timeanddate.com/time/negative-leap-second.html#:....
If dUT1 can become either negative or larger than 1, all such hardware and software must be reviewed and possibly upgraded, to no longer make assumptions about dUT1.
Communication protocols may have to be changed, if there is no way to encode a negative dUT1.
Negative values should already be accounted for, afaict.
> UTC is maintained via leap seconds, such that DUT1 remains within the range −0.9 s < DUT1 < +0.9 s.
I can't imagine why it would ever be constrained to abs(dut) < 1, as that does not appear to be a hard spec anywhere, it's just the goal. But I could see some really stupid implementations, so maybe.
https://en.m.wikipedia.org/wiki/DUT1
The only people who need to pay attention to sun angle are astronomers, and they use their own system based on TAI.
So you are arguing to continue rejiggering a complex and error-prone system that benefits exactly nobody.
UTC has the leap second cause it's not "real time" and so now we're just gonna never sync up UTC to real time at all? How is that the solution? Either we deal with leap seconds or we need to implement something that can't go backwards and properly models time. Leap seconds seem much simpler...
In the end we didn't get rid of SQL cause of SQL Injection. We fixed the frameworks and promoted the solutions. We may simply need to make a push for languages and etc to just properly support time and promote how to do things correctly. It honestly seems easier.
There simply is no definition of solar time that can obey this constraint long term, because the rotation of the earth varies, and varies over time in ways we have a limited ability to predict. This is the entire crux of the problem.
But they have their own solution we need pay exactly zero attention to. Leap seconds in UTC are just as big a nuisance for them as for everyone else. They have TAI, sidereal time, and this dumb bastard UTC with its own hacked up thing that doesn't match their precise alternative.
Meanwhile, making sure everyone agrees as to the kind of time they're talking about it hard enough.
If they stop announcing leap seconds, everything correctly equipped for leap seconds will still work, and everything else that gets it wrong every time will also work.
And those of us who have to make the stuff that works right adapt to all the crap that doesn't and can't be fixed can do other things, instead.
We have IAT if you want a monotonic measure of time: https://en.wikipedia.org/wiki/International_Atomic_Time
Use the right tool for the right job. UTC is what it is. Trying to redefine it is as stupid as redefining a foot so 3 feet are a meter exactly.
Fixing UTC by simply not declaring any new leap seconds eliminates all problems. What used to break on a semi-regular basis stops breaking. Nobody suffers. Nobody pays. No problems surface.
Leap seconds have not sit well with me ever since I learned about them. Messing with the number of seconds in a certain minute a few times a year just seemed ... unclean.
So if fellow commenters are right, that without leap seconds it would take 6667 years for the time to drift just one hour, then leap seconds are absolutely more trouble than their worth, and we should drop it this instant and try to come up with a solution for that leap hour in the next six milleniums.
This is like people saying that we shouldn't have daylight savings so we should redefine GMT to not have DST. That is not only stupid but breaks all use cases where you care about historical DST.
This is why we have UTC, it's GMT - DST. People in 1960 could figure this out. Are we so incompetent that our grandfathers were better programmers than us?
Crap programmers' grandparents were no better than they are. We live with it all. All their code doesn't work right and won't be fixed.
But, stop breaking it with leap seconds, and it will stay not broken.
TAI > UTC > UT1
That said, the hard work to build out a compromise has already been done, so whatever, let's just keep it until political or speed-of-light issues make it awkward to distribute information about leap seconds, at which point dropping them will be an easy and natural solution.
Who's definition... the whole relativeness of time means this is a problem.
Yea, I agree that we should have a unit of time defined for things near sea level and not moving very fast. But even that becomes problematic over 'long' periods of time as the earth is slowing down and will skew from what humans experience, of which has been the basis of how we define time until recently.
Even then we're still leaving out the problems of things in space and on other planets.
At the end of the day we're attempting to define time as something exact for all observers, and when you attempt to give an exact definition to something that is not exact problems are going to occur.
If you define time in terms of days and years, I.e in term of revolutions of the earth around the sun and itself, of course it’s wobbling and deceleration has an impact. If you think it shouldn’t then measure time differently, for example as seconds since a certain instant
Isn’t that what the article is arguing we do? What practical benefit does keeping this historical definition of time give us? Outside of people trying to account for the rotation of the earth precisely who could even notice?
If you really need a 'solar-ish' time, you could also define a fixed function correction for UTC->'solar' and then extend that thousands of years by an order of magnitude. (Sadly the SI second is somewhat far off from the 1/86400th of a solar day, so a big portion of the correction caused by leapseconds is just this predictable portion of the difference).
> If you think it shouldn’t then measure time differently, for example as seconds since a certain instant
Plenty of stuff would love to do that, but we distribute UTC. To get back to "time from an instant" given UTC you have to know about and correctly and consistently handle leapseconds. It's quite tricky, because when an interface hands you UTC you don't know if the latest leapsecond has been processed in it. It's getting even harder recently because the widespready distributed systems failures caused by leapseconds are causing some people to deploy varrious kinds of "leap smear" which smears out leapseconds over some number of hours. Interfaces that are supposed to return UTC now sometimes return leapsmeared UTC with some unknowable choice of smearing scheme.
Arguably the root issue is that we've based out computer timekeeping hierarchy on UTC instead of TAI (or GPS time or whatever non-leaping thing). Had we based everything on atomic time and handled 'UTC' as a presentation layer thing like timezones are normally handled things would work much better. Unfortunately that ship has really sailed. Fortunately, if leap seconds are just not issued essentially everything keeps working without issue for hundreds if not thousands of years.
The handling of timezones and of leap-seconds are orthogonal problems, arising from distinct causes. Leap-seconds are a response to the desire to synchronise an atomic timescale with the uneven rotation of the Earth; timezones (and DST) are strictly a political problem.
Politicians often don't understand the consequences of timezone changes; they often introduce them without giving enough time for people to update their timezone database - sometimes just a few days. The result is that the new timezone is nothing more than a political gesture, because hardly anyone is using it.
I mostly agree with you, but this is a bad example. SQL injection is sadly still very far from a solved problem.
"We have solutions for the most common occurrences" is not the same as "the problem is solved".
What kind of non-argument is that?
the "comment" kind.
Oof classic 3rd rail for when you're arguing with CS grads
Leap seconds are a nuisance and source of bugs in a million programs. Fix them here, fix them there, it will always be wrong in the majority.
We've already done this before, it's called the Gregorian Calendar.
The problem described in the article where "time goes backwaards" only exist when you compare two different time sources, which is always risky, whether a leap second is happening or not.
UTC is a count of seconds. Conversion to HMS is dictated to fool with the S field, but everybody suffers. The seconds count is supposed to actually skip.
Because nobody is going to fix the million programs and gadgets that get it wrong every time.
Who said that time needs to be in sync with rotation of the earth? Nobody, who cares? It's a so small variation happening in a so long period of time to not be noticeable to any practice use: it's not that we take the sun as a reference of time anymore! We can keep counting time as we want and not be bothered with something not precise as the rotation of the earth. And for the applications that require that sort of precision, and only them, adjust the time accordingly.
I mean, a meter was once defined as the one ten-millionth of the distance from the equator to the North Pole along a great circle. It's not that for this reason if the distance between the North Pole and the equator changes we are all throwing away our meters... it's just that we found a more precise definition of one meter. Same happened with the second (and all the time measures, such as a day): we express them in a new format where it no longer matters what the earth and the sun do.
Humans sleep, usually at night time, and the rotation of the Earth defines night in any location, so regardless of the continual tick of some sort of "universal clock" we need a way to measure daily events that humans can use that rely on the sun going up and down at certain times and thus we need to adjust our local Earth times based on it's rotation.
Maybe we can decouple UTC (or whatever) from local times completely, so then a leap second is just a second we add to or remove from the offset for any given location, but we still need to deal with adjusting local clocks to the rotation of the Earth and it's orbit around our star, the "Sun".
This seems like a kind of navel gazing point, however-- without leapseconds it would take on the order of 4000 years to slip an hour, quite a big longer so that nights hours aren't aren't at night.
We already have a good mechenism for matching local sun time-- timezones.
I don't see anyting in your post to justify one second level offsets.
(aside, UT1 is technically defined in terms of earth's orientation with respect to distant quasars, not the sun :) )
These solutions (including daylight saving time, timezone, etc) were probably a good solution where the clock were local and it didn't exist the problem of synchronizing clocks all around the world. But to these day, it doesn't really make a lot of sense sense. Even timezone, it would be far easier knowing that there is only a world clock (UTC) and we adapt our time to the clock and not change the clock.
Timezone, daylight saving, and leap seconds generate a ton of problems only for a minor convenience...
We could wait enough leap seconds to reach 30 minutes and then have a smaller (or bigger) DST timejump and nobody would notice.
I think that's ok if "the future" is 1000 years in the future!
It’s inevitable because we don’t want hours of slip on Earth and eventually we will move to other planets which certainly don’t want Earth leap seconds.
https://www.nasa.gov/mission_pages/tdm/clock/index.html
https://www.jpl.nasa.gov/news/what-is-an-atomic-clock
One of the largest electronic health records systems has code that predates the UNIX epoch. Much of the time handling code is custom written to deal with this. However, the code was so poorly written that the system would lose data during the double 1 am window that occurs during daylight savings time shift. Hospitals would just shut off all of their computers during this time to deal with it.
As the article notes, issues with leap seconds have also brought down reddit and cloudflare. Many people in this thread are treating this like some sort of display of incompetence, but if you've ever written code that deeply interacts with time, you'd know how difficult it is to get right. A sign of a good system is one where it is difficult to fuck up.
IMO it is better to guarantee that time always moves forward rather than trying to match computer time to human time.
https://www.nist.gov/pml/time-and-frequency-division/nist-ti...
It would be like silently changing the start of unix epoch time to 1800 instead of adding a new “Unix time since 1800” and asking people to switch.
This change only affects people who need UTC to be close to UT1 and also somehow don't know what UT1 is.
The people who would be unaffected by the redefinition can already just trivially switch manually (as we already assumed that just redefining things under them would work), leaving the UTC people alone. There is no good reason to silently break all programs carefully designed to use UTC correctly to fix all of the programs haphazardly written by people who did not know what they were doing and used UTC when they actually wanted TAI. Especially since fixing the wrong use of UTC is so trivial that we assume it can be done with no modification.
A few applications should switch standards, the question is whether solar concerned applications should switch to UT1, or continuity concerned applications should switch to TAI. The former is simpler, easier, cheaper, and only causes unexpected behavior (quite slowly), NOT systematic failure.
Not sure if you're playing Cunningham's Law or if you don't know this was the line of thought until everything was so far out of touch with reality, 10 days of time never existed, and official records were kept with dual-dates.
https://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates
https://www.timeanddate.com/calendar/julian-gregorian-switch...
Your example only speaks for the incompetence argument.
In reality, times and dates are really complicated. Luckily, the engineers at Facebook, Reddit, and Clouflare are being paid hundreds of thousands of dollars to show off their expertise. Is it that much to ask for them to read into details like leap seconds?
Would you say to an advocate of C (much less ... rust): Look man, real programmers write in boolean circuits. Programming is hard, sure, but the engineers at Facebook, Reddit, and Clouflare are being paid hundreds of thousands of dollars to show off their expertise. Is it that much to ask for them to read into details multiplication circuits?
:)
Leapseconds causing widespread failures isn't a hypothetical, just like buffer overflows aren't. Yet, in theory, with perfectly competent development ...
Yet even with perfect competence leapseconds are still pretty gnarly: They require systems have a trustworthy and consistent source of the list of leapseconds. ... and they mean that you fundamentally cannot predict the amount of time between two UTC timestamps when one or more of them is more than 6 months in the future... and no amount of competence can fix that.
For timers within a single system, use monotonic clock of your own cpu.
FWIW, there are many things that deal with leap seconds that way too. Too much risk of ending up in a difficult to fix or silently corrupt state, while coming up from a reboot is highly tested and known to work.
The cost of leapseconds is quite significant.
> but if you've ever written code that deeply interacts with time, you'd know how difficult it is to get right.
Good odds that even if someone has that they got it wrong and don't know-- especially when it comes to leapseconds as they're fairly hard to test esp. with distributed systems and infrequent enough that you may not realize the cause even when you've suffered from an issue.
Which says both Google and Amazon smears over a 24 hour period (in contrast to Meta's 17 hour smear).
Though the ship has sailed, I think it could have been much better if computers were set to follow TAI Time (atomic clock time - unaffected by leap seconds) time than the UTC. UTC is as variable as localtime and should have been treated as such.
If fb wants to - they can (and should) use TAI time for system reference.
TAI : https://www.nist.gov/pml/time-and-frequency-division/nist-ti... edit: link
As far as I can tell, TAI will always be offset from UTC by an integer amount of full seconds, and I guess time coordination between large independent systems is mostly useful just when comparing log timestamps (I would guess almost all sensible software uses already account for much larger clock drifts than the current leap second count of 37, right?)
After adopting TAI, Facebook engineers just need to remember that their log timestamps are offset by N seconds from all the others.
Someone should fork the NTP protocol to use TAI instead, and go from there (or at least provide tai offset).
https://en.wikipedia.org/wiki/Precision_Time_Protocol
But that's backwards. A Stratum 1 NTP usually gets its data from GPS, which HAS the offset (GPS runs TAI). But it only outputs UTC, but not the offset, making other programs compute it from TZDATA. Why is NTP making user programs harder to get the data that IT ALREADY HAS? Because philosophically, NTP is married to UTC (even though NTP is mostly for computers!)
And providing this offset would basically get rid of a large body of people (like the TFA) who wants to CHANGE the definition of UTC, which is a more drastic proposal.
GPS time is actually 19 seconds behind TAI at all times.
1. Displaying current time: for that ideally you need the offset directly from the time server because the system timezone data can be out of date in regards to current time.
2. Displaying historical timestamps: for that you use the system timezone file.
There's a draft of the next version of the NTP protocol (NTPv5) at https://www.ietf.org/archive/id/draft-mlichvar-ntp-ntpv5-04.... which not only has the option of working in TAI, but also has explicit support for "leap second smearing". It also has a field to explicitly provide the TAI offset.
Timezones are already backed by a database which needs regular updates, including leap seconds would make sense since those are also updated in an unpredictable manner.
Every time I see ditching leap seconds come up, they never try to explain why TAI won't work for them, leading me to believe they probably just don't know it exists, nor could they even imagine something like it being invented.
https://en.wikipedia.org/wiki/International_Organization_for...
The same reason that KFC (Kentucky Fried Chicken) is PFK in Québec... In French: Poulet Frit Kentucky.
Honestly, it feels more natural for adjectives to follow the noun. I think about this a lot when naming variables.
English is a quirky language.
>Oddly, languages either have the exact same ordering as English, or the exact opposite as English. And, nouns in various languages fall in some designated position between the string of adjectives -- in English it's at the end, in Romance languages it's somewhere in the middle, such that most adjectives follow the noun, but certain adjectives precede
https://linguistics.stackexchange.com/a/997
The real answer is that deeply learning grammar as a child makes you think in grammatically correct ways to begin with, which means that when you start vocalizing a sentence, it's already queued up in grammatically correct form or very close to it. This is why we should teach children grammar grammar grammar and almost nothing but grammar, using poetry for memorization, reading to expose them to grammatically-correct texts, and writing to drive grammar home. And some 'rithmetic.
mostly everything.
I am a native speaker, which means that I didn't realise that british english isn't actively taught. Like we aren't taught grammar in any particular way (apart from I before E, except after C, which is mostly bollocks, because it depends on the origin of the word. [their for example.])
Basically we are dipped in the language and we either succeed, or in my case dumped in remediation. (I can't spell for shit)
I didn't realise this until I was learning another language as an adult. They were usings terms like "present continuous, reflexives, compound verbs, etc" None of which I knew the practical meaning of.
Teaching a child to read, again you just realise that basically its 5 different languages smeared together, with shit all rules. Syntax, yeah we have some, but no native speak can explain the rules. (we have adjective ordering , but I don't know what it is, I can only tell you if you've got it wrong.)
Missing second half of the rhyme: "or when sounded like 'a' as in 'neighbor' or 'weigh'"
Nanoseconds since X is a fairly unambiguous reference (relativity aside).
Use this for any kind of timestamp or recordkeeping. Convert to UTC (or EST, CST, etc.) as necessary for reference to the solar day.
The only reason not to do this is because you have a million systems that are already running on UTC, and you don't want to do a massive leap second erasure to get back to TAI.
From a software development perspective this seems monstrously more complex than just muddling along with the current situation even with leap seconds.
First, consider the question of "what do unix timestamps mean?" The answer is UTC, except just be broken during the second where there's an extra leap second added or removed, and don't try to represent it. They neither represent TAI nor UTC perfectly, and have no way to encode a leap second, but they are very space efficient to store needing only 8 bytes.
Now, we want to start converting our systems over to TAI, great! To do that we need a format to efficiently store a unix time in a binary representation. For this exercise let's use Jan 1, 1970, and so when we call it we get a value today that's equal to unix time plus 37 (the current offset between TAI & UTC). Awesome, now we need a new function to call it in every single language we use, and then migrate all callsites over to it. Try not to miss any places where someone's passing unix time as an int64 instead of, say, a time_t. If you call into libraries that return timestamps make sure you shim them so that you can convert those timestamps from UTC to TAI.
Now, we have the problem of how to store those int64s. We can't store them in place of our current timestamps, they'll be 37 seconds off. So let's add a field to all databases where timestamps are stored to store the TAI version. Additionally, every RPC is going to need to send along both TAI & UTC during the migration process, so change those too. We can't just ignore cases where we need an integer representation of time, either - those have historically been the places where systems break during leap second changes.
I hope this gets to a little bit of why it would be extremely non-trivial to use TAI in place of UTC right now. If you're storing your time as, say, a string representation with a time zone built in you're right, it's actually generally not that bad, and time zone information is frequently encoded in the string. It's _extremely_ difficult to deal with once you move to a representation of time where the timezone isn't directly encoded in a timestamp.
I doubt anyone talking about the elimination of the leapsecond is unaware of TAI but TAI is not readily available on general purpose computers (and, increasingly, UTC is being silently substituted for leap-smeared UTC). And for specialized systems attempts to make pockets of TAI break down when they have to talk to the outside world (and have consistent times with it) and/or due to hardcoded leapsecond tables in software.
If we want to actually solve the problem then let's switch to an interstellar time standard in a rest frame relative to the CMBR as far outside of gravity wells as possible and make that the universal monotonically increasing standard. Then computers can run on that time standard and UTC and friends can be derivatives.
This won't work: since galaxies aren't static, and because the universe expands, the point with the highest gravitational potential ("as far outside of gravity wells as possible") will both move w.r.t. the CMBR and have a gravitional potential that changes over time.
Across all the devices in my house that have a clock in them, the time drift is a little over an hour and it doesn't make the slightest bit of difference to me: internet connected computers being the most accurate.
Between individual computers, thanks to filesystem semantics, drifts of up to 2 seconds are expected and generally considered "identical" - it certainly doesn't matter for file sync applications.
So either we want to build a time standard that can be transformed in a sensible way to all the others which are useful - in which case something which works for interstellar timekeeping would be a sensible step, given that relativistic issues crop up even in Earth orbit, or we're building a time system "for humans" in which case everything we have now is fine, and will by definition be messy because time and timezones change all the time.
It's just for distributed systems the OTHER ways of dealing with the problems leapseconds create (e.g. using a local monotone clock) aren't available. But even where they are available leapseconds still create issues because they're extremely difficult to test and are often handled somewhat incorrectly.
UTC without leapseconds would in no way be less "for humans". After 4000 years of drift the effect on the solar noon would be about the same as you get driving to the next state over.
Leap seconds are still seconds so even with GPS sync, if all you're doing is tracking 1000ms increments then we have a format already which doesn't have them.
In unix time there are 86400 "seconds" per day since the epoch. On days when there is a leapsecond the timestamp of the leapsecond is given out for two (TAI) seconds.
A result is that unix time stays in sync with UTC and the difference between them doesn't change.
The belief that conventional unix time is somehow leapsecond free is a common source of leapsecond handling bugs. :( It results from misleading standards text which states that it doesn't have leapseconds, which it technically doesn't-- instead leaves the second undefined, which implementations distort to make unix time match UTC.
If your goal is to measure accurate durations, synchronize distributed systems, or point telescopes-- unix time will not solve any of your leap second issues.
It's plain weird to rewrite the world which doesn't actually care about leap seconds for use-cases which don't work in normal human reaction or processing times. 1000ms is a value only relevant to high precision applications, which are perfectly fine not being tied to a precise date or solar rotation or anything.
This feels like a programmers without science training issue: all models are models and you choose the one useful for your purpose. It's particularly galling coming from Meta who are large enough to just do this, write the code, and submit a standard for consideration by the tech-industry.
All we need to do is simply choose not to announce that all the software in the world that (might have) "got leap seconds wrong" but still has to talk to the other half that (might have) "got leap seconds wrong" will be officially broken, this year. Or next year. Etc.
Timex(TM) Watches, now featuring Puslar(TM) Time.
The difference between potential already need to get handled on earth. Esp. since the NIST labs in boulder are at about 5400 feet.
Humans want noon to be when the sun is overhead, and midnight to be the middle of the night. Almost nobody cares about sub-second accuracy or monotonic time. Track it that way internally if you like, but humans want time to correlate to what they see out the window.
So, if we stop actually caring about normal time, why should we care about leap seconds either...
It is exactly the problem. Why should every software system everywhere have its own complicated, unpredictable, error-prone fudge that benefits literally nobody?
Imo society needs three distinct time counting systems.
1. Linux time. Essentially a universal addressing system for the measure of time in a agreed upon reference point (Earth’s surface). This should be the standard for science/computation, with the need for language to describe time dilation when comparing two reference points. Unix time doesn’t have leap seconds, or the concept of days.
2. UTC aka civil time. Things such as the orbit of the sun and the rotation of the earth aren’t in constant speed and don’t divide evenly with each other. UTC deals with short term variability with leap days and leap seconds. This is so every January 6th the earth is roughly in the same spot relative to the sun, and every 5pm the earth is in roughly the same part of its rotation. This is important because these things drift on human scale timelines. This calendar should be used for daily life, business, etc.
3. A purely astronomic calendar. A calendar that defines time by astronomic events. For example, defining a day as one rotation of Earth and not as a number of times an atom vibrates. This should be used so we can discuss astronomical events such as “A Martian year” or a “Saturn Day” and provide some meaning. This is the basics that should be taught to elementary school children to establish the cultural meaning of a day or a year and to provide some basic learnings of nature.
If we used a unix-time-including-leap-seconds instead then the date/time conversion functions would need to have a little extra smarts (a table of leap seconds in addition to a timezone database) but most of the leap second related problems would not exist.
(We already deal just fine with months having variable numbers of days. Minutes having variable numbers of seconds is obviously awkwardly rare from a testing point of view, but not fundamentally more difficult to get correct.)
The fundamental difference is that we can predict well in advance how many days will be in a given month, and the rules for calculating that number can be implemented with a short lookup table and a few modulo operations.
The lookup table for past leap seconds, however, is already longer than 12 entries, and there is no way of calculating the length of all future minutes.
On the other hand, the problem may be simpler than keeping track of changes to timezone definitions, since there are hundreds of jurisdictions that can unilaterally change those.