Did you read TFA? It's literally the first line of the second paragraph.
The decision was made by representatives from governments worldwide at the General Conference on Weights and Measures (CGPM) outside Paris on 18 November.
It is "a valid synecdoche" only as long as we accept that doublethink and newspeak are desirable. Sure, calling black — "white", dictatorship — "worldwide democracy" and so on… everyone will adjust. And by "will" I mean "already do and always did" — there's nothing new about this, it's just the "truths" we are supposed to believe in are what changes over the centuries, not the way societies work. Perhaps it's even true that there is no other way (which doesn't make me like it any more).
So it's totally true that no one is actually mislead by this, but I absolutely understand those who try to pretend they are, and have a slight disdain for those who try to defend this bullshit.
I... uh... it's a normal phrase. Dunno know what to tell you. You're not gonna get a lot of takers on this being "bullshit". Feels like you're mad about something big and taking it out on random irrelevant things.
There's maybe an argument to be made that using language which implies the legitimacy of organizations as presenting "all of us" is a sort of supremacist way to act, because it casually legitimizes whoever happens to be in power without questioning where they got that power or whether they earned or deserve it.
But, like, it's a standards body. If the world didn't have one it would want to go and make one and then be back where we started. This isn't the interesting battlefield for that kind of point.
I would only want qualified people and not laymen voting on this. It's technical, not social. It has little bearing on anyone's lived experiences apart from scientists and engineers.
> The decision was made by representatives from governments worldwide at the General Conference on Weights and Measures (CGPM) outside Paris on 18 November
Once leap seconds actually stop TAI-UTC will presumably just have a constant offset. Constants are kind of irrelevant since they are very easy to deal with. Really no different than GPS time being exactly 19 seconds off TAI.
> How, and whether, to keep atomic time in sync with Earth's rotation is still up for debate.
[…]
> The CGPM — which also oversees the international system of units (SI) — has proposed that no leap second should be added for at least a century, allowing UT1 and UTC to slide out of sync by about 1 minute. But it plans to consult with other international organizations and decide by 2026 on what upper limit, if any, to put on how much they be allowed to diverge.
So everything about this hasn't quite been sorted out yet.
At some point there may need to be a reckoning like was done with the calendar:
> Second, in the years since the First Council of Nicaea in AD 325,[b] the excess leap days introduced by the Julian algorithm had caused the calendar to drift such that the (Northern) spring equinox was occurring well before its nominal 21 March date. This date was important to the Christian churches because it is fundamental to the calculation of the date of Easter. To reinstate the association, the reform advanced the date by 10 days:[c] Thursday 4 October 1582 was followed by Friday 15 October 1582.[3]
As annoying as handling a leap second could be, if it happens even somewhat regularly it can be testing more often. Deciding in the future to do a 'one-off' event may be more challenging from both a coördination point of view, as well as trying to handle a rare event correctly in (e.g.) code.
If you would detonate the moon, break it up into small pieces and smear them out over its orbit, tidal friction would cease. Tidal friction is a major component of the earth's rotation's slowdown.
I hated the fact that you had to get 9/10 through the book to find out how it derived its name. The number 7 appears right at the start, but it's a misdirection.
Freeman Dyson figured out how to do that along time ago, he was more interested in speeding up rotation to disassemble a planet but the same method can be applied to set the rotation to a given speed.
just build a planetary motor.
encircle the earth with ferromagnetic coils, then fire asteroids (similarly banded) at the earth in a series of near misses the magnetic drag steals or imparts angular momentum depending on the direction of the asteroid relative to the earth.
The drift is sufficiently slow that you can fix it with a "leap hour" when needed -- perhaps once every five thousand years. This could be handled for civil/local time via an adjustment in the timezone definitions (something which happens a few times a year today), leaving the underlying UTC timebase unchanged.
> This could be handled for civil/local time via an adjustment in the timezone definitions (something which happens a few times a year today), leaving the underlying UTC timebase unchanged.
Like I said: it could become a huge coordination problem.
it's really just a tzdata update for the vast majority of computer systems. That package updates several times a year. Get the revised rule in there a decade in advance and you're golden.
> it's really just a tzdata update for the vast majority of computer systems.
I don't think you understand how the tzdata works: the tzdata folks only update the contents after the civil authority for a region changes the law.
So first you have to get all the law makers to update what the legal statues say and then you "just" update the computer systems. The latter is the 'easy' part, it's the former that's the coordination problem.
And as someone who was around for the 2005 DST change, I can say that may also be quite the coordination problem. (Though I think code has gotten much better since then.)
Let them handle it in the future when it becomes an issue, in roughly 500 years (that's when the lack of leap seconds will sum up to roughly 30 min). If they still care about having the sun above London at exactly 12 (or whenever it is in ut1) they can handle it.
That's a feature, not a bug. UTC adjustments require world-wide coordination.
Timezone adjustments do not. They are fundamentally a local matter, and just need to be communicated to the tireless maintainers of tzdata, and can happen incrementally any time an area feels local time is too far off solar time.
Then let's skip the leap hour too: just let UTC and UT1 diverge up to 86400 seconds and compensate that by changing the time zones when needed. Then, when the drift reaches 86400 seconds, the clock times are aligned again. At this point we just need to re-align the dates too, and this can be done by skipping February 29 on a leap year (which should be quite easy to implement in software).
Is that practical? Drift is slow and takes 1 min per century. Let’s say you can live with 10 minutes of drift. That leaves minutes [10-50] which is 4 centuries vs minutes [50-10] where it’s fine which is 2 centuries.
Also, if the problem were time zones, time zones already support non-whole hour shifts, so why not just apply the leap second into all time zones? The reason is that that isn’t what a leap second is. It’s kind of “how much time has elapsed since 1970 midnight” and that number is corrected for with leap seconds. Time zone offsets don’t help you here.
And timezones one hour wide impose about a +/- 30 minute fixed error (and sometimes larger) on top of that - the difference between local mean time and local civil time.
We have an implicit assumption for definitions of noon and midnight right now. I can't tell if that assumption will be there 1000 years later, but assuming that, UTC and UT1 can't really differ by much more than several hours.
My understanding is that clocks in Greenwich are set to utc+1 from the last Sunday of March until the last Sunday of October. (They call it British Summer Time).
Each leap second event causes hundred of millions of dollars worth of disruption and that's not including the disruption created by leapseconds even when they're not happening (e.g. the frequent false leap seconds) or the mini-disaster we're sure to experience should there be a negative leap second (which we are still trending towards).
The delays are unfortunate because it's harder to transition applications that need UT1 to use an offset from UTC when the available time sources are still unpredictably and unreliably leaping on you (since to apply a UT1 correction you need your UT1 offset and your UTC source to agree if and how a leap second has been applied).
From a practical perspective it would be better to immediately discontinue leaping, then UTC would immediately become a stable time that adjustments could be applied against for those few applications that need them. It would also save us from a negative leap second.
So we make things worse for humans in order to make it easier for computers?
Yah, one second doesn't matter, but it builds up.
This: "Or we could even decouple our sense of time from the Sun entirely, to create a single world time zone in which different countries see the Sun overhead at different times of day or night."
Shows that they are completely disconnect from human reality: "Science already doesn’t use local times, we talk in UTC."
That's great for science, but people care about day vs night.
I struggle to understand how we benefit that much from the same wall clock times mapping roughly to the same times of day across time zones. It seems like there's pros and cons to both ways and there's no clear "better" option when it comes to the human experience. Meanwhile, doing away with timezones also does away with a lot of complexity both in computing and other areas (e.g. scheduling across timezones)
> Yah, one second doesn't matter, but it builds up.
I don't think it's that big of a deal; do you really care what the perception of "11 in the morning" is for someone 1,000 years ago? This kind of thing is pretty cultural anyway, and a slow drift over a thousands of years doesn't really matter.
The main reason we have the "new" Gregorian calendar is because of religious reasons, not because people were having huge practical problems with the old (slightly less accurate) Julian calendar.
Plus the current leap second system won't really deal with the long-term drift anyway because the earth's rotation keeps slowing, so in a few hundred years we'd need more leap seconds than the current system allows, and eventually we'd need a "leap second" every day because the day is a second longer (around the year 6000 IIRC).
Religion was only half the reason for the Gregorian calendar reform. Church and state, being interlinked and intertwined, the civil calendar was gradually slipping away from correct calibration with the equinoxes and thus the seasons. So it was important for farmers and mariners and politicians to all have a reliable calendar that matched what the Earth was actually going through.
It just so happened that the religious authority in the West was able to make a significant change to the civil calendar which also happened to match the Church calendar, and it was adopted by all of Christendom, eventually even Asia and the four corners of the Earth have accepted it as universal and not so religious.
That was I was told in history lesson, too, but I'm not so sure that was all that important of a reason, otherwise it wouldn't have taken hundreds of years for people to adopt the new calendar. The drift is so slow that a week more or less over a period of 1,000 years is easily something that can slowly be adjusted to by farmers, politicians, and the like (unlike, say, the Roman calendar before Caesar reformed it which drifted by several days every year).
I agree with you quite a bit here, although I'm of the persuasion that this one minute a century drift is nothing, you already deal with orders of magnitude worse when you go visit family in another time zone for example, and you're fine.
I think this goes along the lines of the great DST debate, the US is going to do away with the changes next year and make DST permanent. Not do away with it, keep it, forever.
Fundamentally we create these abstractions and begin to rely on them and then decouple how we operate from the real world. We created the clocks to measure the position of the sun in the sky, now we ignore the sun entirely, the clocks are god now. I don't think it's a good thing generally speaking, but on this particular issue, I don't think people are going to really feel anything different happening, it will decrease the engineering burden to constantly maintain and update systems, which means decreased resource consumption, with no noticeable impact on the day to day lives of anyone except those engineers relying on exact time measurement.
Because we have to distinguish the two concepts. With timezones we already did it: computers save time (usually) in UTC format, and time is converted to the user time zone only when displaying it (at an higher level).
This is obviously better, when you save a file for example you don't care about the region of the user, and thus the save timestamp of the file should really be an absolute number, so if you take your laptop and go from one country to another your whole system doesn't break because it sees timestamps in the future, same thing when daylight saving is applied and the clock is brought back/forward by an hour.
Leap seconds, if we decide that we should keep them (to me not, because the difference is so little that we would start to notice that in centuries, and who knows not which computer systems we will have but if humanity still exists), should really be handled at time zone level, by shifting of an offset that contemplates leap seconds, and not by slowing up/accelerating clocks.
Solar noon, or the solar meridian, is the time of day in which the sun is highest in the sky. If our times were completely natural, solar noon would be at 12 PM exactly.
Today, the solar meridian in Madrid is at 12:59 PM, while the solar meridian in Belgrade is at 11:23 AM. This is because Madrid and Belgrade are within the same time zone, in order to more easily coordinate European commerce.
If that's an acceptable tradeoff, I don't really see the issue in drifting something on the order of dozens-to-hundreds of seconds per century.
Less than you think. A part of the leap second is correcting an unpredictable random walk. The random walk part does not add up.
The linear drift part does add up. We're still talking several thousand years to end up with just an hour offset.
Just switching to a new timezone every few thousand years ("As of Jan 1st 6022, fifty years from now, all usage of Eastern timezone will switch to New Eastern timezone, which is an hour ahead.") would handle your civil usage concern fine.
(and then in year 10022 they can switch to New New Eastern timezone, if there are any survivors of world war 5...)
How is this supposed to work? The rotation of the earth is not a constant. So we either scrap UT1 ("the atomic clock") or UTC ("the calendar"). Neither sound like an actual option. The latter would imply that at some (far off) point in the future you wake up at like 10pm as UTC and UT1 are now entirely mismatched (you may as well get rid of all time zones at that point).
> The CGPM — which also oversees the international system of units (SI) — has proposed that no leap second should be added for at least a century, allowing UT1 and UTC to slide out of sync by about 1 minute.
UT1 - based on Earth's rotation only, strictly 86400 seconds per day; length of each second varies; takes a heck of a lot of effort (and time) to measure accurately.
UTC - has same length of a second as TAI, but (for now) tracks UT1 to a precision of +/- 1 second. To achieve that, can have days that are 86399, or 86400, or 86401 seconds long.
None of 3 is planned for scrapping. The only change discussed in TFA is to fix UTC day to 86400 seconds (at cost of letting it drift further away from UT1).
I'm not saying that we can't, but saying that we can seems quite brave (and by "brave" I mean foolishly reckless) without actually trying it. I, for one, am not so sure. There is a lot of stupid stuff about calendars and clocks (of which DST is worst by far), but at least nothing is really drifting.
Is it important that midnight is actually midnight? I don't know. I would prefer it to be, but perhaps I can just update my knowledge on when the midnight actually is once or twice a year. Perhaps it isn't a big deal at all. But I wouldn't dare to claim that "surely there can be no problems with it".
And, yes, that kinda means I don't support the leap second removal. It wasn't great, but eventually fixing the software written by incompetent people sounds more like a solution, than breaking the existing solution and making both competent and incompetent people alike eventually come up with a new one (to abolish it as well after 100 more years).
> Is it important that midnight is actually midnight?
Midnight is almost never at midnight.
Let's talk noon, specifically solar noon, as it is easier to visualize. Solar noon varies throughout the year, and based on the position in the timezone.
Solar noon for two cities in Eastern Time Zone:
11:29:16 - Boston
12:22:36 - Atlanta
Tomorrow, solar noon in Atlanta will be 12:22:50, 14 seconds later than today. No one notices a 14 second shift from one day to the next. As you can see, solar noon is almost never at clock noon, yet no one complains about that. Who would notice a 1 minute shift over 100 years?
The programming problem is made vastly more difficult because the leap seconds are not known in advance. When a new leap second is announced, every dependent system has to be updated.
I propose waiting a thousand years, so that the difference builds up to an hour, and then handle the adjustment as part of the daylight savings reform, which should just about have worked its way through the U.S. Congress and the EU institutions by then.
No. You’d need to actually change all the calendars. for example, an event recorded as happening at UTC 0 doesn’t get changed by a time zone change. And yet the hour you’ve accumulated is a “real” hour that’s accumulated in the number of seconds you think has elapsed since 0. You could of course keep track of when those leap seconds applied but now you have to have an almanac to compute the difference between two time stamps to account for all the smearing.
So there are two things to note. First is that it takes a long time for the seconds to add up, and second is that when we're looking into the deep future the current system of leap seconds won't be enough even if we do keep them.
In my opinion, leap seconds are accumulated so slowly that the impact of abolishing leap seconds won't be noticeable in daily life for a couple hundred years.
As the article said, many countries jump forwards and backwards an entire hour twice a year and after the adaptation period we don't notice
> The latter would imply that at some (far off) point in the future you wake up at like 10pm as UTC and UT1 are now entirely mismatched (you may as well get rid of all time zones at that point).
We (or our descendants) can try to fix Earth rotation. All is needed is a big enough rotating mass with a variable speed of rotation.
Hot take: Leap seconds caused by astronomers refusing to modify their own software, instead getting the rest of the world to modify theirs. Too facile?
Look at astronomical software, e.g. xephem. There will be a "clocks" tab that displays a number of different clocks, TAI (atomic clock, no leap seconds), UTC (global civil time), media solar time (GMT, which ISN'T UTC) and finally, derived from the aforementioned "sidereal time", which is the one you really need to adjust your telescope. Sidereal time is derived from a year with 1 more day basically, because the earth moving around the sun adds 1 more rotation of the background stars. Which is a drift of roughly 4 minutes per day.
Oh, and then there is stuff like Julian date which you need to look up the myriads of catalogues and tables you need for corrections because everything "wobbles" even more than you'd think.
Yes, dropping leap seconds will remove 1 table lookup from the above. But astronomical time systems are so complex that that change is a drop in the ocean.
Any modern positioning system needs an accurate clock. Leap seconds aren’t completely predictable, so you can’t deploy something like a GPS unit with future leap seconds encoded. These computers are often spread across vast distances, so it’s the most difficult thing to possibly update.
Wouldn't a positioning system just need accurate time differences and synchronization between transmitters?
E.g., suppose you made a system where each satellite transmits messages of the form "Here comes beep #N. At the time of beep #N this satellite is at this position: <X>, <Y>, <Z>. Here is beep <N>: BEEP!".
The satellites are synced so that beep <N> occurs at the same time on all of them.
By looking at the time difference between the arrival of beep <N> from several satellites a receiver could tell the differences between its distances from those satellites. Combined with the position information for those satellites at the time they beeped the receiver would be able to tell its location.
If the satellite broadcasts use a high enough frequency and that frequency is known and very stable the receiver would not even need an accurate stand alone timer. It could sync a counter to the frequency of the satellite radio.
Astronomy commonly uses TAI or raw GPS time. In fact if you look at video footage from NASA control rooms and such there's usually a GPS second clock up on the wall somewhere.
The motivation for leap seconds wasn't astronomers, but to just keep civil time tied to solar time long term. However, the unpredictability of these leap second additions has proven to be pretty annoying, causing bugs and such. This is why google and others actually "smear" the introduction of their leap seconds over half the day.
Considering the current difference is 37 seconds, its natural to wonder if this is worth it. Certainly most people wouldn't notice relative to dawn dusk for a very long time, long enough that the entire concept probably wouldn't even make sense anymore. So why not just stop? That's the basic argument here.
Nah. Its common for astronomy to use GPS time and then apply the corrections from BIPM Circular T to get UT1.
For sophisticated astronomy systems the elimination of leap seconds should simplify and reduce a source of errors. As it is, since Circular T is against UTC you need to take your local source of time and worry if leap seconds have been correctly applied (apply leap seconds to gps time or make sure haven't been fed smeared NTP time or other horrors) before you can get UT1.
Fairly casual astronomy, no-- but that isn't driving international standards, and there mechanical uncertainties dominate so you'll end up doing a 1-star correction in any case which immediately corrects the clock.
> Or we could even decouple our sense of time from the Sun entirely, to create a single world time zone in which different countries see the Sun overhead at different times of day or night.
A very interesting idea, but probably much too progressive.
I've wanted to do this for years. Every time I mention this to someone I get a surprisingly visceral reaction against it even when they can't think of any real reasons why this would be bad.
Do they really not have a reason or do they not want to put in 15 minutes of effort to explain something that has already been explained a thousand times?
I'm for this. Get rid of timezones, AM, PM, DST, leap years, seconds, all of it! Imagine having to know just one time. It takes a bit to wrap your head around. But only because we've accepted all the confusion for so long. The sun is still going to be "up" in one part of the world and "down" in another. The little numbers on your clock don't change that. Why can't it be the same little numbers everywhere?
I see people bringing this question up as a counter-argument for a unified time.
But how do you know whether the sun is up or down in any given place on Earth right now? You probably don't, if the place is a few thousand miles East or West from where you are. You'd have to look up its time zone. And doing that might not be that much different from looking up at what hour the solar noon is somewhere else.
You could do that, sure. Whenever I want to schedule a meeting with someone in Zurich, I could reason “15:00 UTC is about an hour before solar noon for me and — looking it up — about four hours past for him. Reasonable time for a meeting.” This would prove so useful in practice that people would rapidly start referring to times that way when talking to people from abroad: “sorry I couldn’t take your call, it was seven hours past solar noon for me; I was having dinner.” Everyone would memorize their location’s offset from UTC and use it colloquially all the time.
Oh wait, we’ve reinvented time zones!
Basically, the point of time measured in hours and minutes is to be useful to humans in daily life. And it’s useful to have a common language for things relevant to humans.
I'm for that as well. Some minor issues that I've thought of. Currently the day changes (Mon -> Tue) at midnight local time. If the day followed UTC, then would California change from Mon->Tues at midnight UTC, which is 4pm currently?
Yes it varies unpredictably based on changes in the distribution of mass within the Earth from magma flows, air currents, ice pack movements, ocean currents, and so on.
It would surprise me if we could not measure and detect any variation in the earth’s rotation.
A leap second is on the order of less than 0.000001% variation, at least according to the leap seconds applied recently.
Basically, things like the weather can influence the speed of rotation. Angular momentum changes when mass is closer to the center of gravity or farther out. That measurably includes mass like water in clouds and leafs on trees.
More like the precision of ± 0.5 seconds / year, that is to say 15 parts per billion, is that ludicrous. For comparison, time acceleration in geostationary orbit due to general relativity is somewhat less than one part per billion. Household tools (other than clocks) rarely go beyond a percent, and if you need a particular quantity you don’t have a ready-made tool for you’ll likely going to be hard-pressed to go beyond ten percent.
The more precise you want to be, the more complex and numerous physical phenomena you need to consider become; with a system as involved as the Earth, at some point you get to weather-like chaotic behaviour, so no practical amount of additional precision in input data helps anymore.
It doesn't help that the atomic second was defined using old data such that when it was defined we were already relatively far off from 86400 seconds/day. A relatively large part of the correction being applied by leap seconds comes from this initial offset, which is also why all leap seconds so far have been in one direction. (and why the handling of the other direction is essentially completely untested, making the prospects of a negative leap second in near-ish future pretty frightening).
We don't really do that on a second accuracy though. We need to add a whole new day to the calendar every four years to make up the difference. Meanwhile we've added less than half a minute worth of leap seconds.
We already accept an error of half an hour (most timezone offsets are multiples of a whole hour) or more (many timezone boundaries are widened to align with state or country boundaries). A couple of minutes is nothing next to that, and if start getting too far, we can simply redefine the timezone offsets (which we already do twice a year in many places, and any device which might be moved across timezone boundaries already have to deal with that).
The slowdown is the long-term trend caused by drag of the Moon's gravity, but the speedups are sporadic and as a result of events such as massive earthquakes that cause the Earth's rotation to speed up as some significant mass falls further to the Earth's center. The conservation of angular momentum is the principle that leads to those brief speed ups, but they will not fully counteract the longterm drag caused by the Moon.
Currently software has to be built to accommodate leap seconds. They happen frequently enough that you'll find out within a few years whether your software breaks when time suddenly skips forward or backward.
If we kick the can down the road such that eventually we'll need to add a leap minute, we're going to end up with software that was never written to expect time to change in such a way, hasn't had a real world test of the change for decades, and will have no one working on the software who ever had to deal with such a change.
It's going to be much worse for software reliability to have a leap minute on the order of once a century than a leap second every few years.
In an enterprise environment, every leap second or TZ change invokes a ceremonious updating of anything using Java or a JVM. I suspect a lot of people would rather perform a once a century update than the bi-annual process they do now.
The thing is that there will be entire Java-like ecosystems that will have shorter longevity than the time between leaps. So practically all of them will have no facility for a leap at all.
You're right, but I'd argue this problem is already here.
Thanks to glaciers melting, earth rotation is (temporarily) accelerating. Because of that, positive leap seconds, regular before, didn't happen since 2017 - so there could very well be (recent) software out there that has that code-path broken, and nobody noticed yet.
And due to exact same geophysical effect we might see a negative leap second - something that never ever happened before. What are the odds that every single piece of software gets that one right?
Interesting point. Just like a skater pulling their arms in, snow melting and running to lower ground would make the earth spin faster (and let's add in the extra erosion). Sea levels are rising though (due to both thermal expansion and runoff).
Be interesting to estimate the size of the various effects (no doubt I've missed plenty of others) but is it really true that a change in sign of the acceleration of Earth's angular velocity is down to climate change?
I don’t think that’s right. I would think the effect of melt of glaciers on mountains would be negligible and the effect of the poles melting and sending that water down to the poles would slow down rotation, like an ice skater pushing their arms out.
I've always thought that the best way would just have leap seconds every six months, and have it be ± 1 second no matter what - so sometimes you'd go back a second twice in a row, and then go forward a second to get back to correct.
From 2035 it's going to be less accurate in exactly the same way. I'd argue bombcar's method is more robust.
I don't know of anything that actually requires UTC to be within 1 second of average rotation-based time; having it within 2 or 3 seconds is extremely unlikely to actually break anything. But we do generally want to have measured time roughly in line with Earth time in the medium to long term.
Today it is within I think +-3 hours of earth time (China being the worst offender), because of timezones and DST. If it ever gets worse than half an hour in a country, they can always change the timezone... or just, like, change businesses' opening hours and stuff.
How about clocks on Mars? Should these have Earth leap seconds? Time synchronization is already hard enough, complicating it with adjustments based on uneven planetary body movements doesn’t make much sense in a long term.
In the longer term Mars should probably have its own time scale. When we get to further colonization maybe we can use TAI for interplanetary use (but time dilation due to relativity effects is going to be a problem when going to other stars) while still using UTC on Earth.
The problem is that if the originating system didn't record the time in utc, you've lost the information needed to make the time unambiguous. What's 2022-11-06 01:30 USA/San Francisco in UTC?
People expect e.g. their "daily power consumption" to end at midnight local time. When they zoom in on the daily aggregates, they don't want a spike to suddenly disappear just because it belonged to the next local day and you only stored UTC-day aggregates. Even more so for billing.
Henceforth every minute will be "bell curve distribution around 60" seconds long, and each hour will be "bell curve distribution around 60" minutes long.
This variability will provide excellent fuzzing of all time libraries everywhere.
Odd. I was wondering how fast it actually was long term, and this rate from historical record seems much lower. They cite 1.8ms/century if I'm reading it correctly with some odd cyclical thing going on. " the change in the length of the mean solar day (lod) increases at an average rate of +1.8 ms per century. "
I mean, we've added 22 seconds over 50 years. Although at current rate it would still just be 7 minutes after a millenia :)
Why would we ever need a leap minute? Just let time zones drift. Unless you happen to be at the exact longitude for which your time zone is correct, the sun's not at its highest point in the sky for you at exactly noon anyway.
Eventually, thousands of years from now when time has drifted by an hour or more (assuming modern technological civilization even still exists by then), each jurisdiction can just change their time zone's offset from UTC, without coordinating with anyone else. Jurisdictions making time zone changes is a well-understood situation that we already know how to deal with.
The last part is right and is also why we have this problem.
Leap seconds are an architectural blunder that always belonged in the abstraction layer that lines up the sun with the rotation of earth (the time zone abstraction). It never belonged in the part that counts seconds.
Why bother? A calendar year is 365.242 days long... time is already off by about 3/4 of a day the year before a leap year, what does adding a second here or there really do?
Time is not off by about 3/4 of a day, calendar is. And hardly many people care about planet's position relative to the Sun (on the orbit) — I mean, they can, if it is important for they occult rituals or something, but probably they learned to work with it over the centuries already.
Earth's rotation relative to the Sun is whole another deal.
Indeed; the converse would be to add (or remove) micro-leapseconds in order to keep accurate time. That way it would happen so often that the code would get tested and we'd have working implementations (maybe we could fix the traditional Apple issues with leap years at the same time).
It's going to be centuries until the difference between astronomical midnight and UTC midnight is more than an hour, which is the exact same amount of error we deliberately inflict on ourselves to have more daylight in summer evenings and half the error that residents of Spain experience by as a consequence of the political decision to join the same time zone as Berlin. If human civilization exists long enough for this to be an actual problem, we're probably going to have to figure out how to coordinate time with multiple space settlements, which is going to be a much harder problem thanks to time dilation.
The rate of drift is so slow that people will never care.
Even over thousands of years when an hour of drift is accumulated there won’t be a manual adjustment - people will have just gotten used to different times of day having sunlight, with generations having been born and died with mean solar time happening at 11am.
Eventually the rotation of the earth may change enough that drift accumulates too quickly and leap time needs to be added, but that’s only going to be true thousands to tens of thousands of years in the future.
clocks get used for two distinct purposes, often at odds:
- the measurement of durations.
- the presentation of some timestamp in a way that the reader has some intuition for.
that first purpose won’t be hurt by not tracking leap seconds. actually, a lot of applications will probably more accurately measure durations by eliminating leap seconds.
if leap seconds (or minutes) really are of critical importance, we’ll reintroduce them to the presentation layer. the thing is, very few people can tell the difference between 12:01 and 12:02 without being told the “real” time. so if you’re presenting a time which is “off” by a minute because there’s no leap seconds… does it really matter?
I agree with your separation between "duration" and "absolute point in time". But it doesn't solve the issue, because durations are often computed as the difference between two absolute points in time. You could get over this on your local machine with a local counter, but across network boundaries you need to rely on absolute differences.
> But it doesn't solve the issue, because durations are often computed as the difference between two absolute points in time.
other way around. e.g. unix time is determined by the number of seconds (as experienced by some point fixed to Earth, roughly) relative to some reference point. duration is the native format for most time systems, like UTC, because “absolute time” isn’t a thing that can be measured. faking the duration (e.g. adding leap seconds) within a time system is sort of nonsensical: we only do it to make translation across time systems (UTC, UT1, local/human timezones) simple. if that’s the justification for things like leap seconds, then better to keep the time system itself in its most native format (assuming that format is useful locally) and explicitly do those conversions only when translating, i.e. at the network boundary: when communicating with a system that doesn’t share/understand our time system(s).
There should really be three "layers" of time indirection.
1) Seconds since 00:00:00UTC 1.1.1970. This value increases by 1 each atomic second and never goes forward/back. Call this Universal Monotonic Time.
2) The difference between when the sun is at its zenith at Greenwich and 12:00 UMT. Call this the Astronomic Drift.
3) The timezone - offset from Greenwich that makes the local clock sync up with astronomic time and also contains a DST offset if that location observes DST at that date.
By adding up 1) + 2) + 3) you end up with the "human time" at a given location at a given date.
A computer system should only ever store 1). Then, it can calculate human time when displaying it to humans.
I'm also a fan of having "local sun time" which would be the time according to the position of the sun in the sky, quantised to 15-minute slices (basically micro-timezones). It would be nice if office hours, school times, &c can be defined based on that, i.e. work starts at 9am local sun time, which will sync up better with people's biological clock and cut down on the yearly stress DST causes.
Of course they do. But government bodies and other institutional bodies incarnated these standards organizations in order to better coordinate with one another, and decided and committed to defering to them a long time ago. Russia is a sovereign state, they can make any decision they want to, but they decided and agreed at some point to defer to this organization for a reason.
> Russia is a sovereign state, they can make any decision they want to, but they decided and agreed at some point to defer to this organization for a reason.
I think the commenter means that there isn’t a technical reason that GLONASS can’t be changed to not add leap seconds not that Russia doesn’t have to defer to an international body.
In prior advocacy for the elimination of leap seconds, I found that many of the officials appointed to talk about this stuff are fairly clueless about the engineering.
I wouldn't be too shocked if they asked "what uses leap seconds", got an answer, and are advocating on that basis ("We have systems that use leap seconds!"), without having actually asked better questions like "What would require expensive changes if no more leap seconds were issued?"
Those are very different scenarios, they aren't equivalent.
Leap years have to do directly with the sun, what day and time the equinoxes happen every year and the like. This time noticeably drifts every year, even every day, computers or not.
These leap seconds and what not have to do with very sensitive instruments measuring time very precisely. These time measures are entirely about machines.
That's simply not true at all, and that was my whole point. Leap seconds have nothing to do with precise measurement because they are nothing more than calendar adjustments, just like leap days. They have the same purpose too; leap seconds keep sunrise and sunset in the right place over long periods of time just like leap years keep equinox and solstice in the right place. Note that leap years, an invention millennia old, account for drift on millennial scales, with the 400 year rule for example. This disproves the theory that there is some modern obsession with exactitude which sets leap years and leap seconds apart, because leap seconds too deal with significant drift on the same scales.
Only the madness of "smearing seconds" and other workarounds for broken software with incorrect calendar implementations makes them seem different.
It seems I've got an unpopular opinion reading the comments here, but having some leap seconds from time to time ensure we are able to manage them.
But "no leap second should be added for at least a century" ensures there will be a y2k reckoning every century. Seems short sighted to me, even if it is not a game-changing issue, let's be honest.
Leap seconds are not useful. We do not need to use them anymore. While yes you are right in that more leap seconds makes it easier to handle leap seconds, it is just better to not have to worry about leap seconds altogother. It is unneeded complexity that helps no one.
Why have them at all? how many people do things where they actually matter? at the current rate it'll be ~9000ad before we hit an hour offset, and we do hour offsets twice a year, so if an hour off is okay why is 1 second off not?
The critical question is whether they'll have to leap forward or fall backward. We simply cannot abide stealing an hour of sleep from our cyborg/transhuman descendants. We'd never live it down.
Hopefully by the time they need to make an hour's adjustment, we'll have done away with the anachronism that is DST. So then they'll have to learn to do it all over again from scratch.
The Julian Calendar was good enough for centuries after the empire that invented it had fallen, which I think counts as good enough in general. That said, I'd love to read a story about tracking down some time bug a million layers of abstraction down from the state of tech in 9000AD.
The thing is, we've remade calendars many times in the past millennium and our current calendar is not gospel. Sidereal drift can and should be addressed with a calendar fix, not a clock fix. The clock's a clock, the calendar's a calendar. It doesn't matter if we can make our clocks calendar-like because they shouldn't be anyway.
> we do hour offsets twice a year, so if an hour off is okay why is 1 second off not?
The actual Unix time does not change when the clocks are switched between daylight saving time and standard time. Only the time zone changes.
When a leap second occurs, the actual Unix time changes, which can lead to bugs, e.g. when a positive time difference comes back as negative. To prevent such issues, a monotonic clock can be used to measure time intervals.
Edit: OK, just re-read some docs, looks like POSIX chose the worst of all options and decrements the timestamp experiencing the same second twice...
Wrong info from before edit: Unix time doesn't change either, it's the number of seconds since 00:00:00 UTC on 1 January 1970, though systems may or may not ignore that and set it to match the UTC time.
Yes. It does. Op is correct. A leap second specifically is an adjustment because “how many seconds since 1970” changes because the earth’s rotation isn’t constant speed. UTC tone definitely changes. If it didn’t then you wouldn’t hear anything about it and it would just be transparently folded into your time zone database.
And that timescale is called TAI. It's always been an option, but for whatever reason, people (and standards) (collectively) use UTC but want it to act like TAI.
The difference should be handled at the same layer as time zones, which is already a mess and is already well-suited to deal with this type of thing.
I'd argue there should be no adjustment until it gets to be +- 15 minutes from UT1. And even then, NO clock skewing, just a time zone adjustment across the board.
Its not a leap once a century thing, it's a rejigger the timezones by an hour every four to five thousand years. (either define new zones one hour over or redefine existing ones)
We already rejigger the time zones from time to time, so thats already handled. It's still a source of issues, sure, but it's once source instead of two.
The timezone rejiggering could also be set hundreds of years in advance... rather than the very short notice we get for leap seconds.
I've never really understood why smearing the leap second is such a big deal. Surely if you have software that is going to be sensitive to small variation in the clock over 24h, you're already not using wall time.
Storing anything as UTC was a mistake and we should be using TAI for all storage and computation, only transforming into more human friendly formats for display to end users. This never needed to be a problem except we decided to make it harder to use TAI than UTC and so everything got built up off the backs of legacy bios level hardware supported UTC style clock behaviour, when we should have been using TAI from the start. Yes I know it would have been harder, but we got off our collective asses and decided to fix our short sighted decision making for Y2K date storage, why not this… if it truly costs as much for everyone to endure a leap second why wasn’t it just fixed from the bottom up and rebuilt correctly!
Datetime storage would consist of two explicit parts: one free from leap seconds (similar to the raw timestamp you get from a GPS receiver), and description of when leap seconds happen, so that you can transform the leap-second-free timestamp into UTC. Feels like a more robust way in principle to me.
TAI is monotonic clock, and isn't adjusted for solar time of day, it could be considered universal as TAI would be the same between any 2 points, but UTC is adjusted for earths rotation, so a theoretical mars UTC would end up out of sync with earth UTC.
EDIT: info below is incorrect about UTC not being monotonic, as pointed out in thread but is useful for monotonic vs non-monotonic:
In UTC you can jump forward or back, so it's possible to do an operation after another operation but have a timestamp before it, which is bad for many reasons, top being auditing.
do operation one at T0
do operation two at T1
do operation three at T-1
in TAI it would always be
do operation one at T0
do operation two at T1
do operation three at T2
Yeah you are right, when a leap second is introduced it becomes 23:59:60 (monotonic) in utc, while with unix-time a normal way to handle it is to repeat 23:59:59 twice (non-monotonic).
A negative leap second means that 23:59:59 is skipped, you go from 23:59:58 to 00:00:00, which is monotonically increasing, in both UTC and unixtime.
Positive leap seconds are monotonically increasing in UTC, where you get 23:59:60 between 23:59:59 and 00:00:00, but not in typical implementations of unix time where 23:59:59 repeats, and with milliseconds you go (breifly) 58.999 -> 59.0 -> 59.999 -> 59.0 -> 59.999 -> 0.0
If you're only counting seconds, then both UTC and unixtime are always monotonically increasing.
I now realized that the parent meant everything should have been TAI from the beginning, which is indeed a valid take. We can't switch to TAI today only because we are already using UTC.
Original comment: Only those who never tried to actually use TAI yourself can claim that you can use TAI instead of UTC without a problem.
I'm not sure I support your "hot take" — it is hot and requires a lot of contemplation. But that's not the point, IMO.
The point is, that there ALREADY EXIST both TAI and UTC. TAI is true monotonic (whatever it means in a relativistic universe) and doesn't make any compromises. UTC abolishes monotonicity in order to keep both the length of a second and the time relationship to the orbital rotation. They both work. For whatever reason (for obvious reasons that is, but doesn't matter) UTC was chosen in virtually any software system to keep time.
So, ok, if there is a suspicion of leap seconds being unnecessary. How about moving from UTC time to TAI then? Let's keep UTC as it is, keep adding leap seconds and just make it a best practice to rely on TAI for all datetime operations and world clock synchronization? Maybe it will work out, maybe it won't, but at least you won't be breaking a perfectly working alternative (currently — mainstream) system.
The more I think about it, the more outrageously stupid abolishing leap seconds seems.
If you want to keep UTC matching the solar rotation, why do you specifically require leap seconds? Why not leap minutes? Or leap milliseconds? The choice of ±1 s as the acceptable error seems arbitrary.
It is worthwhile to look at the past; before leap seconds the disagreement with UT1 was handled by changing the rate of UTC slightly, and that's probably even worse than leap seconds. And for a while the unit of adjustment was less than a second, varying from 0.05 to 0.2 seconds. I believe enough people have complained about subsecond adjustments, and thus leap seconds have survived only because not enough people have complained at that time.
Because a minute is a huge amount of time (and, by the way, don't forget, that minutes don't exist, I just understand that you mean 60 seconds) and there is no such thing as "leap milliseconds" because UTC is literally just counting seconds. Basically, UT1 already is an implementation of what you call "leap milliseconds". Not literally, but achieves the same thing. And it is way too complicated to use it in practice outside of astronomy-specific tasks.
So, to sum it up:
- TAI is a real thing, it has a concrete meaning, and it's "leap infinity".
- UT1 is a real thing, but is unusable in practice, and you could think of it as "leap ms"
- UTC until yesterday was a real thing, meaning time, which has seconds equal to TAI-seconds, but not drifting from UT1 for more than 0.9 s. Since today it's broken and I'm not sure what it even means anymore — I mean, not in practice, but "platonically".
- Nobody just introduced a standard that would mean "time with seconds equal to TAI-seconds, but not drifting from UT1 for more than 59 s" yet. I guess you could be the one to do it, but I'm not sure it would get a wide adoption.
Eliminating leap seconds was only a half measure. They should have finished the job by adding rockets to the Earth to ensure that its rotation will stay at exactly 24 hours.
If they weren't going to do that, then why eliminate leap seconds? Kicking the problem down the road doesn't really solve the problem, it just makes it worse later.
Surely it’s all the test firings of Merlin and Raptor engines that’s slowing the earth down in the first place? I mean first he screws up twitter, now it’s time itself.
It rotates itself in 23 hours and 56 minutes relative to the fixed stars. It rotates itself in 24 hours relative to the Sun. It is Earth's rotation relative to the Sun what people care about in most situations, because day and night depend on that, not on the position relative to some far-away stars.
> For whatever reason (for obvious reasons that is, but doesn't matter) UTC was chosen in virtually any software system to keep time.
What was chosen really isn't UTC. Several UTC seconds in the past are not accurately representable in unixtime. Several unixtime seconds in the past are ambigious as to which UTC second they are.
Unixtime is awfully close to UTC time, but it's not the same. If UTC time stops inserting leap seconds and never has negative leap seconds, then they will be equivalent going forward.
Not really. I mean, it's true that we should distinguish between the 2 and everything that you said about the difference is also true. But unixtime doesn't really "exist" in a sense UTC and TAI do. It is rather an imperfect implementation of UTC, that chooses to ignore (or repeat) some seconds.
You can hear that unixtime is the number of seconds passed since X. But it isn't really true though. The number of seconds is number of seconds, it isn't defined by our standards, it just exists. And TAI is a fair representation of how many seconds on Earth actually passed (on average) since whatever.
UTC kinda does it as well by virtue of 1 second being equal to 1 TAI second, but it actually counts (counted until yesterday) the number of Earth's rotations. It's just every rotation (represented by 24H) sometimes consists of more than 86 400 seconds.
Unixtime on each individual device counts nothing. It imperfectly represents UTC timestamp received over NTP. Some timestamps are represented twice by the same value. Of course, you can just put your device offline and call it "unixtime" whatever number of seconds it counts since any moment, but you know it will drift away from any meaningful "real" time soon enough.
(Also, it's not even entirely fair to say, as you did, that it is unixtime that was chosen by all the software. Many programs store datetimes as strings. Usually, they still don't support "23:59:60" anyway, but that doesn't really make them unixtime. Unixtime is a timestamp encoding.)
So, that's basically what I'm talking about: you can just make unixtime an implementation of TAI (as opposed to UTC). You can build a new calendar format for it, introduce a new name (not UTC!) for it and see how well it does when all the world slowly drift from Earth's rotation to keep up with TAI. Maybe it actually is fine, I'm not a judge for it (because it really is complicated and I didn't decide yet if it's a good solution or not). But why the fuck would you destroy UTC for it?! It is a closest usable representation of UT1, which doesn't stop to exist! Leave it be!
Consider that the most widely deployed time standard outside the UT framework is GPS time, which was initially synced with UTC but is de facto TAI-19, because it turns out that constant-rate monotonic time is useful and UTC fails at even the alleged astronomical use-case.
As spacecraft start making return trips to Earth we'll run into similar adjustment problems because TAI doesn't progress at the same rate at different altitudes and accelerations, so there'll need to be a re-sync at some point. Satellites already have a similar problem but can just use direct synchronization with Earth since it's so close. In theory spacecraft could do the same direct synchronization to Earth time, but e.g. a computer on the dark side of the moon would need additional relay(s) to stay in sync.
I'm not sure why we don't define an intergalactic time standard and approximate that everywhere with NTP-like protocols; one monotonic clock at rest (with respect to CMBR) in free space. The second is weirdly defined/tracked in Earth's gravity well.
Most of the accurate timekeeping is needed by computers, not humans. We can always define local human time with an affine transform from a coordinated monotonic clock.
The clocks that were used to build TAI (its a co-ordinated average of dozens of atomic clocks around the world) became sufficiently accurate that the difference in each second based on the altitude of the clock measuring it in the early 70s. As a consequence of this it was decided that as of 1 January 1977 00:00:00 TAI would be corrected to correspond to what TAI should be if measured by clocks at the geoid (mean sea level) and as a result it has no relation to altitude or accelerations. There is also (because metrologist are like this sometimes) a continually published version of what TAI was before 1 January 1977 00:00:00 but it is now named EAL (Échelle Atomique Libre, meaning Free Atomic Scale)
In addition to this, we have already designed and maintain equivalent time standards to TAI, but for the Earth's barycentre Geocentric Coordinate Time (TCG - Temps-coordonnée géocentrique) which is roughly speaking TAI for a clock orbiting the sun, where the earth moon barycentre orbits, but without the earth & moon gravitational influence... and for the entire solar system Barycentric Coordinate Time (TCB, from the French Temps-coordonnée barycentrique) which is roughly speaking again, equivalent to a TAI style clock but this time subtracting the entire solar system, as if a clock keeping TAI was just orbiting the galaxy at the barycentre of the entire solar system.
The cutting edge of this is building up astronomical data on ultra stable pulsars to use as "external" reference clocks far outside the solar system, but the complexities of subtracting the effect of all the universe the pulsars' radiation beams pass through before they get to us, makes it quite challenging. But the utility for deep space navigation has made it an active funded path of research for at least the last decade. (to get a GPS equivalent at lunar distance and beyond where it becomes rapidly impractical to have a GPS like orbiting constellation due to inverse square radio broadcast power limits, good radio can pick up GPS at the moon but the location precision out at that distance... is not great)
The cosmic microwave background dipole may be indicative that we can use it as an absolute frame of reference but settling that with enough certainty to base an official time standard on it, seems like some time away based on the state of things between cosmology, astronomy, astrophysics and metrology.
Arguably, being able to perform calendar calculations without leap-second information (which you don’t have for the future) is more important in applications than maintaining to-the-second accuracy over calendrical timescales.
What applications and date-time libraries should really do is differentiate between timestamps, calendar plus wall-clock time, and elapsed runtime. In most circumstances, only the latter would really need to be consistent with TAI.
You don't have dst offsets for the future either. Those keep changing. That's not a blocker.
The straight up truth is that we created something in between. Some parts of earth sun alignment are in the time zone abstraction layer and leap seconds are in the seconds count layer. There's no real cause for this and we should have moved to TAI to fix this blunder long ago.
You don't have DST offsets at all in UTC, which is probably how you are storing timestamps, so you can always compute a delta between timestamps if you don't have leap seconds.
That's the whole point i'm making here. UTC and leap seconds could always have been separate in the same way timezone+dst offsets are separate. In fact leap seconds could have just gone into the timezone offsets directly and it'd all work fine (we'd probably still call it UTC +10 rather than UTC +10:00:27 but that's not a problem and to be honest we'd probably not bother at all until the offset was big anyway).
There's no reason this wasn't done many years ago except for a blunder on the part of CGPM which they are now working to correct.
Absolutely! A large part if h the blame here rests on Unixtime (which is a monotonic count of seconds elapsed) trying to use a time standard where those seconds are not innfact monotonic. Unixtime is basically “TAI done wrong” and the failure to correct this early on … ideally they should have aligned themselves to TAI instead of UTC since originally Unixtime was not actually aligned to any particular time standard then in the mid 70s it was decided to align it with elapsed seconds of UTC time as of a fixed date.
This decision just dominoed down through time causing enough friction that we computer programmers outweighed the metrologists and they caved and abandoned properly keeping UTC in order to stop causing problems for everyone else due to our continued failure to fix the root cause of these issues.
The same way you add a full year without knowing if a country will change timezones or vote to drop daylight savings: you distinguish between timestamps and calendar dates, and keep updated your timezone/leap second database.
That doesn't answer my question. What I mean is that "a day" is not a fixed length, but depends on the existence of leap seconds. Most days have 246060 seconds, but not all.
Say I have a timestamp in the future, and I want to add a day to this. Then the first approximation would be to add 246060 seconds. However if there occurs a leap second in that day, the correct thing is to add one more second. But I do not necessarily know today, if there will be a leap second. So I cannot compute the correct timestamp.
You have to differentiate between calendrical and chronological calculations.
So to walk through your requested example…
You store a TAI time stamp of when you originally chose a specific date/time and then you store either a chronological time stamp (the TAI value) or a calendrical timestamp which is a struct/dict/etc storing the desired year month day, time and timezone and notionally the calendar system unless you want to assume the Gregorian calendar and risk confusion with Julian calendar dates which are still in use for astronomical record keeping. With these two values you can calculate what to change in the struct to account for any time change, a day not being fixed as a number of seconds allows accurate calendar calculations. You increase the day value and make sure you don’t have to “carry” a month in the months column.
Yes this is more calculations when modifying a value compared to just adding a bunch of seconds but that’s the issue at the heart of this problem, calendars and chronological elapsed seconds are fundamentally different and we computer programmers tried to take a big shortcut by using a single seconds value for both… and thus… here we are with the present state of affairs.
> more human friendly formats for display to end users.
This is what's doing the very heavy lifting in your proposal. Leaving aside not knowing when future leap seconds will occur (and thus getting mismatches when broadcasting to different computers that may or may not get the information about the leap seconds at different times) the sheer fact of the matter is that software developers are users too. They will take shortcuts and display TAI as UTC because "something, something people are lazy or uneducated."
We do not need leap seconds. We never should have implemented them. They are a scar on our software for potentially hundreds of years already for any application that seeks to have high accuracy over time.
Time is very frequently a join key or part of a join key in a database and these small differences mean countless hours wasted to investigate "couple of record" mismatches.
Hear hear. Computers should store TAI and convert to human time using leap seconds, time zones and DST offsets. I wonder if we could roll the leap second into the timezone and just remove UTC entirely (or rather make UTC an alias for TAI).
> [the CGPM] decides that the maximum value for the difference (UT1-UTC) will be increased in, or before, 2035
> [CGPM requests that the ITU] propose a new maximum value for the difference (UT1-UTC) that will ensure the continuity of UTC for at least a century
I think there are a few possible interpretations of this:
- We'll readjust UTC in a century (why would you do this to yourself, please no, nobody wants this) by setting a predicted maximum that'll last 100 years
- The maximum is now 1 hour, we'll adjust clocks the same way we adjust for DST
- The maximum is infinite, UTC is now TAI + the same integral offset forever
I'm hoping for the last one, but who knows. They've once again kicked the can down the road to the next 2026 meeting to decide what the increase in max UT1/UTC difference will look like.
> The CGPM — which also oversees the international system of units (SI) — has proposed that no leap second should be added for at least a century, allowing UT1 and UTC to slide out of sync by about 1 minute.
So, in one century, we'll get 1 minute's worth of drift.
Recall that we all share the same clock within timezones, and 1 minute of drift between atomic & solar clocks is the equivalent of traveling 1/60th of your timezone's width to the east or west ... something many people do every day as part of their commute. _Everyone's_ clock deviates from their local solar noon, and _nobody cares_.
Put another way: (at most) one north-south line in your timezone will have solar noon & clock noon line up. Over time the relative location of that line will move. Fine. Let's not screw with our clocks in an effort to keep the location of that line fixed.
I can barely wrap my head around the idea of living in UTC when I remember that, my friends and I already feel like the sun sets too soon these days. We're just so used to 9:30pm sunsets during summer!
The problem is mostly (or so I’ve heard) that the drift is relevant for astronomical applications, and they rely on time dissemination which is done in UTC. If UTC decides to start deviating from TAI by dropping leap seconds, those applications will be in trouble. I’m sure that the problem is overblown, but this is the reasoning that was put forward in the past.
People who are using time for astronomical applications will simply have to track the offset if they need to. I'm not sure how that's much more problematic than the current situation.
Agreed. _Someone_ has to deal with the drift between astronomical time and earth time, better the class of software that deals with space than every time critical system in the world.
But leap seconds hose up astronomical applications too. They all start with TAI and then apply corrections as needed. There are lots more corrections than leap seconds, but they're applied proportionally, not as leaps.
Leap seconds are a solution in search of a problem.
Most systems rely on network time from a canonical time source. Wouldn't it be enough to do the leap second smearing/adjustment there to free the end systems from dealing with that?
455 comments
[ 2.9 ms ] story [ 428 ms ] threadThe decision was made by representatives from governments worldwide at the General Conference on Weights and Measures (CGPM) outside Paris on 18 November.
Of course, that’s an absurd interpretation.
So it's totally true that no one is actually mislead by this, but I absolutely understand those who try to pretend they are, and have a slight disdain for those who try to defend this bullshit.
There's maybe an argument to be made that using language which implies the legitimacy of organizations as presenting "all of us" is a sort of supremacist way to act, because it casually legitimizes whoever happens to be in power without questioning where they got that power or whether they earned or deserve it.
But, like, it's a standards body. If the world didn't have one it would want to go and make one and then be back where we started. This isn't the interesting battlefield for that kind of point.
[…]
> The CGPM — which also oversees the international system of units (SI) — has proposed that no leap second should be added for at least a century, allowing UT1 and UTC to slide out of sync by about 1 minute. But it plans to consult with other international organizations and decide by 2026 on what upper limit, if any, to put on how much they be allowed to diverge.
So everything about this hasn't quite been sorted out yet.
At some point there may need to be a reckoning like was done with the calendar:
> Second, in the years since the First Council of Nicaea in AD 325,[b] the excess leap days introduced by the Julian algorithm had caused the calendar to drift such that the (Northern) spring equinox was occurring well before its nominal 21 March date. This date was important to the Christian churches because it is fundamental to the calculation of the date of Easter. To reinstate the association, the reform advanced the date by 10 days:[c] Thursday 4 October 1582 was followed by Friday 15 October 1582.[3]
* https://en.wikipedia.org/wiki/Gregorian_calendar
As annoying as handling a leap second could be, if it happens even somewhat regularly it can be testing more often. Deciding in the future to do a 'one-off' event may be more challenging from both a coördination point of view, as well as trying to handle a rare event correctly in (e.g.) code.
Close to the plot of a recent Stephenson sci-fi novel:
* https://en.wikipedia.org/wiki/Seveneves
I'm sure kibwen had in mind a Hollywood explosion, whereby a detonated object ceases to exist, rather than turning into many smaller objects.
just build a planetary motor.
encircle the earth with ferromagnetic coils, then fire asteroids (similarly banded) at the earth in a series of near misses the magnetic drag steals or imparts angular momentum depending on the direction of the asteroid relative to the earth.
Like I said: it could become a huge coordination problem.
* https://en.wikipedia.org/wiki/Gregorian_calendar#Adoption_by...
* https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale...
I don't think you understand how the tzdata works: the tzdata folks only update the contents after the civil authority for a region changes the law.
So first you have to get all the law makers to update what the legal statues say and then you "just" update the computer systems. The latter is the 'easy' part, it's the former that's the coordination problem.
And as someone who was around for the 2005 DST change, I can say that may also be quite the coordination problem. (Though I think code has gotten much better since then.)
Timezone adjustments do not. They are fundamentally a local matter, and just need to be communicated to the tireless maintainers of tzdata, and can happen incrementally any time an area feels local time is too far off solar time.
Also, if the problem were time zones, time zones already support non-whole hour shifts, so why not just apply the leap second into all time zones? The reason is that that isn’t what a leap second is. It’s kind of “how much time has elapsed since 1970 midnight” and that number is corrected for with leap seconds. Time zone offsets don’t help you here.
And timezones one hour wide impose about a +/- 30 minute fixed error (and sometimes larger) on top of that - the difference between local mean time and local civil time.
Each leap second event causes hundred of millions of dollars worth of disruption and that's not including the disruption created by leapseconds even when they're not happening (e.g. the frequent false leap seconds) or the mini-disaster we're sure to experience should there be a negative leap second (which we are still trending towards).
The delays are unfortunate because it's harder to transition applications that need UT1 to use an offset from UTC when the available time sources are still unpredictably and unreliably leaping on you (since to apply a UT1 correction you need your UT1 offset and your UTC source to agree if and how a leap second has been applied).
From a practical perspective it would be better to immediately discontinue leaping, then UTC would immediately become a stable time that adjustments could be applied against for those few applications that need them. It would also save us from a negative leap second.
Yah, one second doesn't matter, but it builds up.
This: "Or we could even decouple our sense of time from the Sun entirely, to create a single world time zone in which different countries see the Sun overhead at different times of day or night."
Shows that they are completely disconnect from human reality: "Science already doesn’t use local times, we talk in UTC."
That's great for science, but people care about day vs night.
I don't think it's that big of a deal; do you really care what the perception of "11 in the morning" is for someone 1,000 years ago? This kind of thing is pretty cultural anyway, and a slow drift over a thousands of years doesn't really matter.
The main reason we have the "new" Gregorian calendar is because of religious reasons, not because people were having huge practical problems with the old (slightly less accurate) Julian calendar.
Plus the current leap second system won't really deal with the long-term drift anyway because the earth's rotation keeps slowing, so in a few hundred years we'd need more leap seconds than the current system allows, and eventually we'd need a "leap second" every day because the day is a second longer (around the year 6000 IIRC).
It just so happened that the religious authority in the West was able to make a significant change to the civil calendar which also happened to match the Church calendar, and it was adopted by all of Christendom, eventually even Asia and the four corners of the Earth have accepted it as universal and not so religious.
I think this goes along the lines of the great DST debate, the US is going to do away with the changes next year and make DST permanent. Not do away with it, keep it, forever.
Fundamentally we create these abstractions and begin to rely on them and then decouple how we operate from the real world. We created the clocks to measure the position of the sun in the sky, now we ignore the sun entirely, the clocks are god now. I don't think it's a good thing generally speaking, but on this particular issue, I don't think people are going to really feel anything different happening, it will decrease the engineering burden to constantly maintain and update systems, which means decreased resource consumption, with no noticeable impact on the day to day lives of anyone except those engineers relying on exact time measurement.
This is obviously better, when you save a file for example you don't care about the region of the user, and thus the save timestamp of the file should really be an absolute number, so if you take your laptop and go from one country to another your whole system doesn't break because it sees timestamps in the future, same thing when daylight saving is applied and the clock is brought back/forward by an hour.
Leap seconds, if we decide that we should keep them (to me not, because the difference is so little that we would start to notice that in centuries, and who knows not which computer systems we will have but if humanity still exists), should really be handled at time zone level, by shifting of an offset that contemplates leap seconds, and not by slowing up/accelerating clocks.
Today, the solar meridian in Madrid is at 12:59 PM, while the solar meridian in Belgrade is at 11:23 AM. This is because Madrid and Belgrade are within the same time zone, in order to more easily coordinate European commerce.
If that's an acceptable tradeoff, I don't really see the issue in drifting something on the order of dozens-to-hundreds of seconds per century.
Less than you think. A part of the leap second is correcting an unpredictable random walk. The random walk part does not add up.
The linear drift part does add up. We're still talking several thousand years to end up with just an hour offset.
Just switching to a new timezone every few thousand years ("As of Jan 1st 6022, fifty years from now, all usage of Eastern timezone will switch to New Eastern timezone, which is an hour ahead.") would handle your civil usage concern fine.
(and then in year 10022 they can switch to New New Eastern timezone, if there are any survivors of world war 5...)
UT1 - based on Earth's rotation only, strictly 86400 seconds per day; length of each second varies; takes a heck of a lot of effort (and time) to measure accurately.
UTC - has same length of a second as TAI, but (for now) tracks UT1 to a precision of +/- 1 second. To achieve that, can have days that are 86399, or 86400, or 86401 seconds long.
None of 3 is planned for scrapping. The only change discussed in TFA is to fix UTC day to 86400 seconds (at cost of letting it drift further away from UT1).
Is it important that midnight is actually midnight? I don't know. I would prefer it to be, but perhaps I can just update my knowledge on when the midnight actually is once or twice a year. Perhaps it isn't a big deal at all. But I wouldn't dare to claim that "surely there can be no problems with it".
And, yes, that kinda means I don't support the leap second removal. It wasn't great, but eventually fixing the software written by incompetent people sounds more like a solution, than breaking the existing solution and making both competent and incompetent people alike eventually come up with a new one (to abolish it as well after 100 more years).
Midnight is almost never at midnight.
Let's talk noon, specifically solar noon, as it is easier to visualize. Solar noon varies throughout the year, and based on the position in the timezone.
Solar noon for two cities in Eastern Time Zone: 11:29:16 - Boston 12:22:36 - Atlanta
Tomorrow, solar noon in Atlanta will be 12:22:50, 14 seconds later than today. No one notices a 14 second shift from one day to the next. As you can see, solar noon is almost never at clock noon, yet no one complains about that. Who would notice a 1 minute shift over 100 years?
The programming problem is made vastly more difficult because the leap seconds are not known in advance. When a new leap second is announced, every dependent system has to be updated.
We would use UTC. UT1 would end up only being used by astronomers and whoever else cares about the Earth's rotation.
By the time UTC and UT1 diverge enough to matter, humanity will have either destroyed itself or come up with a new time standard.
As the article said, many countries jump forwards and backwards an entire hour twice a year and after the adaptation period we don't notice
We (or our descendants) can try to fix Earth rotation. All is needed is a big enough rotating mass with a variable speed of rotation.
It seems like JPL (NASA) and the scientific community have defined two currently used sets of time standards for observations from Earth and from space near Earth. https://en.wikipedia.org/wiki/Time_standard#Time_standards_f... Barycentric Coordinate Time (TCB) and Geocentric Coordinate Time (TCG) with DE430 as the current revision of their standard https://en.wikipedia.org/wiki/Jet_Propulsion_Laboratory_Deve...
Look at astronomical software, e.g. xephem. There will be a "clocks" tab that displays a number of different clocks, TAI (atomic clock, no leap seconds), UTC (global civil time), media solar time (GMT, which ISN'T UTC) and finally, derived from the aforementioned "sidereal time", which is the one you really need to adjust your telescope. Sidereal time is derived from a year with 1 more day basically, because the earth moving around the sun adds 1 more rotation of the background stars. Which is a drift of roughly 4 minutes per day.
https://en.wikipedia.org/wiki/Sidereal_time
Oh, and then there is stuff like Julian date which you need to look up the myriads of catalogues and tables you need for corrections because everything "wobbles" even more than you'd think.
Yes, dropping leap seconds will remove 1 table lookup from the above. But astronomical time systems are so complex that that change is a drop in the ocean.
E.g., suppose you made a system where each satellite transmits messages of the form "Here comes beep #N. At the time of beep #N this satellite is at this position: <X>, <Y>, <Z>. Here is beep <N>: BEEP!".
The satellites are synced so that beep <N> occurs at the same time on all of them.
By looking at the time difference between the arrival of beep <N> from several satellites a receiver could tell the differences between its distances from those satellites. Combined with the position information for those satellites at the time they beeped the receiver would be able to tell its location.
If the satellite broadcasts use a high enough frequency and that frequency is known and very stable the receiver would not even need an accurate stand alone timer. It could sync a counter to the frequency of the satellite radio.
Astronomy commonly uses TAI or raw GPS time. In fact if you look at video footage from NASA control rooms and such there's usually a GPS second clock up on the wall somewhere.
The motivation for leap seconds wasn't astronomers, but to just keep civil time tied to solar time long term. However, the unpredictability of these leap second additions has proven to be pretty annoying, causing bugs and such. This is why google and others actually "smear" the introduction of their leap seconds over half the day.
Considering the current difference is 37 seconds, its natural to wonder if this is worth it. Certainly most people wouldn't notice relative to dawn dusk for a very long time, long enough that the entire concept probably wouldn't even make sense anymore. So why not just stop? That's the basic argument here.
For sophisticated astronomy systems the elimination of leap seconds should simplify and reduce a source of errors. As it is, since Circular T is against UTC you need to take your local source of time and worry if leap seconds have been correctly applied (apply leap seconds to gps time or make sure haven't been fed smeared NTP time or other horrors) before you can get UT1.
Fairly casual astronomy, no-- but that isn't driving international standards, and there mechanical uncertainties dominate so you'll end up doing a 1-star correction in any case which immediately corrects the clock.
A very interesting idea, but probably much too progressive.
I believe I just fell in love with that idea. If this would become a social norm people would maybe stop trying to reach me in the morning.
And I would know if it's too late to call others.
But how do you know whether the sun is up or down in any given place on Earth right now? You probably don't, if the place is a few thousand miles East or West from where you are. You'd have to look up its time zone. And doing that might not be that much different from looking up at what hour the solar noon is somewhere else.
Oh wait, we’ve reinvented time zones!
Basically, the point of time measured in hours and minutes is to be useful to humans in daily life. And it’s useful to have a common language for things relevant to humans.
This is surprising to me. Is the Earth's rotation so arbitrary?
The earth even speeds up and slows down in response to stuff like earthquakes and volcanoes.
https://en.wikipedia.org/wiki/Day_length_fluctuations
The more precise you want to be, the more complex and numerous physical phenomena you need to consider become; with a system as involved as the Earth, at some point you get to weather-like chaotic behaviour, so no practical amount of additional precision in input data helps anymore.
Also why does it say the earth is slowing down but this year it sped up. Sounds quite impossible?
Why does being out of sync with the Earth's orbit matter?
We may not care anymore, but emphasis on may.
Edit: TLDR; Local maxima vs. overall trend.
If we kick the can down the road such that eventually we'll need to add a leap minute, we're going to end up with software that was never written to expect time to change in such a way, hasn't had a real world test of the change for decades, and will have no one working on the software who ever had to deal with such a change.
It's going to be much worse for software reliability to have a leap minute on the order of once a century than a leap second every few years.
I can just imagine Graybeards of the future rushing ahead of the leap minute to update the JVM lest the world goes in flames yet again.
Thanks to glaciers melting, earth rotation is (temporarily) accelerating. Because of that, positive leap seconds, regular before, didn't happen since 2017 - so there could very well be (recent) software out there that has that code-path broken, and nobody noticed yet.
And due to exact same geophysical effect we might see a negative leap second - something that never ever happened before. What are the odds that every single piece of software gets that one right?
Be interesting to estimate the size of the various effects (no doubt I've missed plenty of others) but is it really true that a change in sign of the acceleration of Earth's angular velocity is down to climate change?
>If we kick the can down the road such that eventually we'll need to add a leap minute
The drift is not in a single direction. The total drift is not going to be significant for a very long time if ever.
That doesn't stop the (e.g.) FreeBSD folks run tests to make sure things are fine:
* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...
* https://docs.freebsd.org/en/articles/leap-seconds/
Of course there's a whole lot of other userland code besides ntpd.
That'd test all the software paths.
I don't know of anything that actually requires UTC to be within 1 second of average rotation-based time; having it within 2 or 3 seconds is extremely unlikely to actually break anything. But we do generally want to have measured time roughly in line with Earth time in the medium to long term.
The daylight savings time bugs I've run into at pretty much every company I've ever worked at would beg to differ.
This variability will provide excellent fuzzing of all time libraries everywhere.
So this isn't a once-a-century thing, it's adding-a-leap-15-minutes-once-a-millenia issue.
Odd. I was wondering how fast it actually was long term, and this rate from historical record seems much lower. They cite 1.8ms/century if I'm reading it correctly with some odd cyclical thing going on. " the change in the length of the mean solar day (lod) increases at an average rate of +1.8 ms per century. "
I mean, we've added 22 seconds over 50 years. Although at current rate it would still just be 7 minutes after a millenia :)
edit You know, nevermind, that's all covered on wikipedia. https://en.wikipedia.org/wiki/Leap_second#Slowing_rotation_o...
Eventually, thousands of years from now when time has drifted by an hour or more (assuming modern technological civilization even still exists by then), each jurisdiction can just change their time zone's offset from UTC, without coordinating with anyone else. Jurisdictions making time zone changes is a well-understood situation that we already know how to deal with.
Leap seconds are an architectural blunder that always belonged in the abstraction layer that lines up the sun with the rotation of earth (the time zone abstraction). It never belonged in the part that counts seconds.
Earth's rotation relative to the Sun is whole another deal.
The point still stands though - common problems have tested code, uncommon/rare problems rarely have battle-hardened solutions.
Even over thousands of years when an hour of drift is accumulated there won’t be a manual adjustment - people will have just gotten used to different times of day having sunlight, with generations having been born and died with mean solar time happening at 11am.
Eventually the rotation of the earth may change enough that drift accumulates too quickly and leap time needs to be added, but that’s only going to be true thousands to tens of thousands of years in the future.
Plenty is not.
The Swift time type ignores them in its implementation. I filed an issue, and they said there were no plans to implement them.
Good choice it turns out.
Who would of thought that adding a second on random new year changeovers would be worse than letting clocks drift.
Me for one.
We can have a "leap hour" in a thousand years. Till then do we care, I do not, if the clocks and the sun drift very slowly apart from each other?
- the measurement of durations.
- the presentation of some timestamp in a way that the reader has some intuition for.
that first purpose won’t be hurt by not tracking leap seconds. actually, a lot of applications will probably more accurately measure durations by eliminating leap seconds.
if leap seconds (or minutes) really are of critical importance, we’ll reintroduce them to the presentation layer. the thing is, very few people can tell the difference between 12:01 and 12:02 without being told the “real” time. so if you’re presenting a time which is “off” by a minute because there’s no leap seconds… does it really matter?
other way around. e.g. unix time is determined by the number of seconds (as experienced by some point fixed to Earth, roughly) relative to some reference point. duration is the native format for most time systems, like UTC, because “absolute time” isn’t a thing that can be measured. faking the duration (e.g. adding leap seconds) within a time system is sort of nonsensical: we only do it to make translation across time systems (UTC, UT1, local/human timezones) simple. if that’s the justification for things like leap seconds, then better to keep the time system itself in its most native format (assuming that format is useful locally) and explicitly do those conversions only when translating, i.e. at the network boundary: when communicating with a system that doesn’t share/understand our time system(s).
The international standard for monotonic time is TAI, which never had leap seconds, but which is also used by almost no one
1) Seconds since 00:00:00UTC 1.1.1970. This value increases by 1 each atomic second and never goes forward/back. Call this Universal Monotonic Time.
2) The difference between when the sun is at its zenith at Greenwich and 12:00 UMT. Call this the Astronomic Drift.
3) The timezone - offset from Greenwich that makes the local clock sync up with astronomic time and also contains a DST offset if that location observes DST at that date.
By adding up 1) + 2) + 3) you end up with the "human time" at a given location at a given date.
A computer system should only ever store 1). Then, it can calculate human time when displaying it to humans.
I'm also a fan of having "local sun time" which would be the time according to the position of the sun in the sky, quantised to 15-minute slices (basically micro-timezones). It would be nice if office hours, school times, &c can be defined based on that, i.e. work starts at 9am local sun time, which will sync up better with people's biological clock and cut down on the yearly stress DST causes.
I think the commenter means that there isn’t a technical reason that GLONASS can’t be changed to not add leap seconds not that Russia doesn’t have to defer to an international body.
I wouldn't be too shocked if they asked "what uses leap seconds", got an answer, and are advocating on that basis ("We have systems that use leap seconds!"), without having actually asked better questions like "What would require expensive changes if no more leap seconds were issued?"
Oh wait, that's not how it works. And neither is it how leap seconds work.
Leap years have to do directly with the sun, what day and time the equinoxes happen every year and the like. This time noticeably drifts every year, even every day, computers or not.
These leap seconds and what not have to do with very sensitive instruments measuring time very precisely. These time measures are entirely about machines.
Only the madness of "smearing seconds" and other workarounds for broken software with incorrect calendar implementations makes them seem different.
And the leap year problems of the Julian calendar weren't a problem… until they were. And then good luck coördinating things:
* https://en.wikipedia.org/wiki/Gregorian_calendar#Adoption_by...
* https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale...
The actual Unix time does not change when the clocks are switched between daylight saving time and standard time. Only the time zone changes.
When a leap second occurs, the actual Unix time changes, which can lead to bugs, e.g. when a positive time difference comes back as negative. To prevent such issues, a monotonic clock can be used to measure time intervals.
Wrong info from before edit: Unix time doesn't change either, it's the number of seconds since 00:00:00 UTC on 1 January 1970, though systems may or may not ignore that and set it to match the UTC time.
I'd argue there should be no adjustment until it gets to be +- 15 minutes from UT1. And even then, NO clock skewing, just a time zone adjustment across the board.
We already rejigger the time zones from time to time, so thats already handled. It's still a source of issues, sure, but it's once source instead of two.
The timezone rejiggering could also be set hundreds of years in advance... rather than the very short notice we get for leap seconds.
Storing anything as UTC was a mistake and we should be using TAI for all storage and computation, only transforming into more human friendly formats for display to end users. This never needed to be a problem except we decided to make it harder to use TAI than UTC and so everything got built up off the backs of legacy bios level hardware supported UTC style clock behaviour, when we should have been using TAI from the start. Yes I know it would have been harder, but we got off our collective asses and decided to fix our short sighted decision making for Y2K date storage, why not this… if it truly costs as much for everyone to endure a leap second why wasn’t it just fixed from the bottom up and rebuilt correctly!
EDIT: info below is incorrect about UTC not being monotonic, as pointed out in thread but is useful for monotonic vs non-monotonic:
In UTC you can jump forward or back, so it's possible to do an operation after another operation but have a timestamp before it, which is bad for many reasons, top being auditing.
do operation one at T0 do operation two at T1 do operation three at T-1
in TAI it would always be do operation one at T0 do operation two at T1 do operation three at T2
Positive leap seconds are monotonically increasing in UTC, where you get 23:59:60 between 23:59:59 and 00:00:00, but not in typical implementations of unix time where 23:59:59 repeats, and with milliseconds you go (breifly) 58.999 -> 59.0 -> 59.999 -> 59.0 -> 59.999 -> 0.0
If you're only counting seconds, then both UTC and unixtime are always monotonically increasing.
(Negative leap seconds are similar, and do not affect the monotonic property.)
POSIX/Unix timestamps, however, are non-monotonic. But that's a different timescale.
I'm not sure how this differs much in practice from UNIX time
Original comment: Only those who never tried to actually use TAI yourself can claim that you can use TAI instead of UTC without a problem.
That won't break anything...
The point is, that there ALREADY EXIST both TAI and UTC. TAI is true monotonic (whatever it means in a relativistic universe) and doesn't make any compromises. UTC abolishes monotonicity in order to keep both the length of a second and the time relationship to the orbital rotation. They both work. For whatever reason (for obvious reasons that is, but doesn't matter) UTC was chosen in virtually any software system to keep time.
So, ok, if there is a suspicion of leap seconds being unnecessary. How about moving from UTC time to TAI then? Let's keep UTC as it is, keep adding leap seconds and just make it a best practice to rely on TAI for all datetime operations and world clock synchronization? Maybe it will work out, maybe it won't, but at least you won't be breaking a perfectly working alternative (currently — mainstream) system.
The more I think about it, the more outrageously stupid abolishing leap seconds seems.
So, to sum it up:
- TAI is a real thing, it has a concrete meaning, and it's "leap infinity".
- UT1 is a real thing, but is unusable in practice, and you could think of it as "leap ms"
- UTC until yesterday was a real thing, meaning time, which has seconds equal to TAI-seconds, but not drifting from UT1 for more than 0.9 s. Since today it's broken and I'm not sure what it even means anymore — I mean, not in practice, but "platonically".
- Nobody just introduced a standard that would mean "time with seconds equal to TAI-seconds, but not drifting from UT1 for more than 59 s" yet. I guess you could be the one to do it, but I'm not sure it would get a wide adoption.
If they weren't going to do that, then why eliminate leap seconds? Kicking the problem down the road doesn't really solve the problem, it just makes it worse later.
(/s)
The earth rotate around itself in 23 hours and 56 minutes
https://en.m.wikipedia.org/wiki/Sidereal_time
What was chosen really isn't UTC. Several UTC seconds in the past are not accurately representable in unixtime. Several unixtime seconds in the past are ambigious as to which UTC second they are.
Unixtime is awfully close to UTC time, but it's not the same. If UTC time stops inserting leap seconds and never has negative leap seconds, then they will be equivalent going forward.
You can hear that unixtime is the number of seconds passed since X. But it isn't really true though. The number of seconds is number of seconds, it isn't defined by our standards, it just exists. And TAI is a fair representation of how many seconds on Earth actually passed (on average) since whatever.
UTC kinda does it as well by virtue of 1 second being equal to 1 TAI second, but it actually counts (counted until yesterday) the number of Earth's rotations. It's just every rotation (represented by 24H) sometimes consists of more than 86 400 seconds.
Unixtime on each individual device counts nothing. It imperfectly represents UTC timestamp received over NTP. Some timestamps are represented twice by the same value. Of course, you can just put your device offline and call it "unixtime" whatever number of seconds it counts since any moment, but you know it will drift away from any meaningful "real" time soon enough.
(Also, it's not even entirely fair to say, as you did, that it is unixtime that was chosen by all the software. Many programs store datetimes as strings. Usually, they still don't support "23:59:60" anyway, but that doesn't really make them unixtime. Unixtime is a timestamp encoding.)
So, that's basically what I'm talking about: you can just make unixtime an implementation of TAI (as opposed to UTC). You can build a new calendar format for it, introduce a new name (not UTC!) for it and see how well it does when all the world slowly drift from Earth's rotation to keep up with TAI. Maybe it actually is fine, I'm not a judge for it (because it really is complicated and I didn't decide yet if it's a good solution or not). But why the fuck would you destroy UTC for it?! It is a closest usable representation of UT1, which doesn't stop to exist! Leave it be!
They are recommending TAI for storage, compute, and not against UTC for human consumption
Although the easier hack: Abolish leap seconds from UTC!
I'm not sure why we don't define an intergalactic time standard and approximate that everywhere with NTP-like protocols; one monotonic clock at rest (with respect to CMBR) in free space. The second is weirdly defined/tracked in Earth's gravity well.
As long as the Earth exists and you can communicate with people there, there's no practical reason not to use an earth based reference clock.
The clocks that were used to build TAI (its a co-ordinated average of dozens of atomic clocks around the world) became sufficiently accurate that the difference in each second based on the altitude of the clock measuring it in the early 70s. As a consequence of this it was decided that as of 1 January 1977 00:00:00 TAI would be corrected to correspond to what TAI should be if measured by clocks at the geoid (mean sea level) and as a result it has no relation to altitude or accelerations. There is also (because metrologist are like this sometimes) a continually published version of what TAI was before 1 January 1977 00:00:00 but it is now named EAL (Échelle Atomique Libre, meaning Free Atomic Scale)
In addition to this, we have already designed and maintain equivalent time standards to TAI, but for the Earth's barycentre Geocentric Coordinate Time (TCG - Temps-coordonnée géocentrique) which is roughly speaking TAI for a clock orbiting the sun, where the earth moon barycentre orbits, but without the earth & moon gravitational influence... and for the entire solar system Barycentric Coordinate Time (TCB, from the French Temps-coordonnée barycentrique) which is roughly speaking again, equivalent to a TAI style clock but this time subtracting the entire solar system, as if a clock keeping TAI was just orbiting the galaxy at the barycentre of the entire solar system.
The cutting edge of this is building up astronomical data on ultra stable pulsars to use as "external" reference clocks far outside the solar system, but the complexities of subtracting the effect of all the universe the pulsars' radiation beams pass through before they get to us, makes it quite challenging. But the utility for deep space navigation has made it an active funded path of research for at least the last decade. (to get a GPS equivalent at lunar distance and beyond where it becomes rapidly impractical to have a GPS like orbiting constellation due to inverse square radio broadcast power limits, good radio can pick up GPS at the moon but the location precision out at that distance... is not great)
The cosmic microwave background dipole may be indicative that we can use it as an absolute frame of reference but settling that with enough certainty to base an official time standard on it, seems like some time away based on the state of things between cosmology, astronomy, astrophysics and metrology.
I really hope we can get something like TCB standardized for computer use with affine transform to human-usable times.
What applications and date-time libraries should really do is differentiate between timestamps, calendar plus wall-clock time, and elapsed runtime. In most circumstances, only the latter would really need to be consistent with TAI.
The straight up truth is that we created something in between. Some parts of earth sun alignment are in the time zone abstraction layer and leap seconds are in the seconds count layer. There's no real cause for this and we should have moved to TAI to fix this blunder long ago.
There's no reason this wasn't done many years ago except for a blunder on the part of CGPM which they are now working to correct.
But we're here now and we have to fix this. So anything that moves us away front his problem is helpful.
This decision just dominoed down through time causing enough friction that we computer programmers outweighed the metrologists and they caved and abandoned properly keeping UTC in order to stop causing problems for everyone else due to our continued failure to fix the root cause of these issues.
I had to look up TAI. I disagree. UTC exists for a reason. But I am here to tell a war story.
Before I arrived on the scene a customer said they wanted local time in the reports. (As in Wall Clock Time).
The Customer is Always Right. OK?
So the times went into the database as wall clock time.
The designers of the data schema made a simplifying decision to store everything as text.
No time zone went into the text string that described the time. (?? I do not know why. So easy it would have been)
I come along and have to code animations using that time series data.
Very few problems...
As you would expect there are a lot of other problems with that database.
How do you add a full day, if you do not know whether a leap second occured or not?
Say I have a timestamp in the future, and I want to add a day to this. Then the first approximation would be to add 246060 seconds. However if there occurs a leap second in that day, the correct thing is to add one more second. But I do not necessarily know today, if there will be a leap second. So I cannot compute the correct timestamp.
So to walk through your requested example…
You store a TAI time stamp of when you originally chose a specific date/time and then you store either a chronological time stamp (the TAI value) or a calendrical timestamp which is a struct/dict/etc storing the desired year month day, time and timezone and notionally the calendar system unless you want to assume the Gregorian calendar and risk confusion with Julian calendar dates which are still in use for astronomical record keeping. With these two values you can calculate what to change in the struct to account for any time change, a day not being fixed as a number of seconds allows accurate calendar calculations. You increase the day value and make sure you don’t have to “carry” a month in the months column.
Yes this is more calculations when modifying a value compared to just adding a bunch of seconds but that’s the issue at the heart of this problem, calendars and chronological elapsed seconds are fundamentally different and we computer programmers tried to take a big shortcut by using a single seconds value for both… and thus… here we are with the present state of affairs.
> more human friendly formats for display to end users.
This is what's doing the very heavy lifting in your proposal. Leaving aside not knowing when future leap seconds will occur (and thus getting mismatches when broadcasting to different computers that may or may not get the information about the leap seconds at different times) the sheer fact of the matter is that software developers are users too. They will take shortcuts and display TAI as UTC because "something, something people are lazy or uneducated."
We do not need leap seconds. We never should have implemented them. They are a scar on our software for potentially hundreds of years already for any application that seeks to have high accuracy over time.
Time is very frequently a join key or part of a join key in a database and these small differences mean countless hours wasted to investigate "couple of record" mismatches.
Just stop using leap seconds. We will be fine.
To quote the relevant section:
> [the CGPM] decides that the maximum value for the difference (UT1-UTC) will be increased in, or before, 2035
> [CGPM requests that the ITU] propose a new maximum value for the difference (UT1-UTC) that will ensure the continuity of UTC for at least a century
I think there are a few possible interpretations of this:
- We'll readjust UTC in a century (why would you do this to yourself, please no, nobody wants this) by setting a predicted maximum that'll last 100 years
- The maximum is now 1 hour, we'll adjust clocks the same way we adjust for DST
- The maximum is infinite, UTC is now TAI + the same integral offset forever
I'm hoping for the last one, but who knows. They've once again kicked the can down the road to the next 2026 meeting to decide what the increase in max UT1/UTC difference will look like.
So, in one century, we'll get 1 minute's worth of drift.
Recall that we all share the same clock within timezones, and 1 minute of drift between atomic & solar clocks is the equivalent of traveling 1/60th of your timezone's width to the east or west ... something many people do every day as part of their commute. _Everyone's_ clock deviates from their local solar noon, and _nobody cares_.
Put another way: (at most) one north-south line in your timezone will have solar noon & clock noon line up. Over time the relative location of that line will move. Fine. Let's not screw with our clocks in an effort to keep the location of that line fixed.
Leap seconds are a solution in search of a problem.
The great leap-minute crisis of 2147 will be interesting.