UTC, Tai, and Unix Time (2001)
cr.yp.to
cr.yp.to
A. A day is divided into a fixed number of smaller units.
B. Each smaller time unit is of a fixed physical duration.
C. The day cycle corresponds to the cycle of the solar day on Earth.
UTC picks B and C, adding leap seconds to keep track with Earth's solar day cycle.
UT1 picks A and C, redefining the "second" to the changing rate of earth's solar day cycle.
99.999998% of time_t ticks from 1970 until now have been 1 second long. 27 have been 2 seconds long. Therefore B ("each smaller time unit is of a fixed physical duration") is the variant.
POSIX time does not generally work that way. It may seem that way for 1-second resolution timestamps, but at higher resolutions (say millisecond resolution), the clock does not completely stop. It keeps going, jumps backward 1 second, then continues.
I don't think "POSIX time" specifies behavior during leap-seconds for the functions that return timespecs (gettimeofday() [0] and clock_gettime(CLOCK_REALTIME) [1]), so any behaviour would be valid - including smearing or repeating nanoseconds?
[0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/g...
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...
It preserves A (exactly 86400 ticks per calendar day) and C (remains in alignment with UTC) by abandoning B (each tick has a fixed duration)
TAI is an absolute time based on atomic vibrations. UT1 is a relative time based on astrometric systems.
Also, there is no such thing as absolute time, because of relativity. We take pains to account for this by only measuring TAI on the Earth's geoid, but even so the uncertainty never reaches zero. Two "stationary" atomic clocks on the geoid are expected to drift by about a second every billion years or so. Sure, that's pretty good, but definitely no "absolute".
When you really think about it, the cesium atom and the earth's day/night cycle are both equally valid clocks. But the cesium atom measures time more similarly to the way we perceive time on a small scale. But, of course, our lives are scheduled based on the day/night cycle. So they both matter. UTC is the way we reconcile the two.
> B. Each smaller time unit is of a fixed physical duration
This just gave me Timecube flashbacks
Now the BIPM decided to "get rid" of leap seconds in UTC a couple years ago. I hope they come to their senses before 2035 when the change takes effect. Here's what will happen:
Rather than inserting a leap second every 1-2 years to keep UTC in sync with solar time, they plan to defer the problem to once every 100 or so years, and just insert like 50 leap seconds all at once. Think about that for a second. If leap seconds are so bad, how in the hell is the world going to deal with 50 of them at once after a century of oblivious complacency? They won't. They'll just say "Look, it's not worth it to have leap seconds in UTC anymore". Then, UTC will forever be just a constant offset away from TAI.
But we already have TAI. Why not just use TAI as your "source of truth", and let UTC be UTC? We'll have to introduce a new system to take the place of UTC and be in-sync with solar time; like how UTC used to be.
I don't get the insistence on keeping nominal seconds-alignment (or even minutes-alignment) between the clock and the sun's position; we already don't experience it in practice.
Timezone regions are fudged all over the world[1] for political and practical reasons, but even if they weren't, people living near one timezone edge don't experience the "sun noon" at the same time as people living near the other edge, even though they share the same clock time.
[1] just look at the map here: https://en.wikipedia.org/wiki/Time_zone
But completely getting rid of leap seconds for UTC is misguided. We already have TAI, which is literally just UTC without leap seconds. If leap seconds are messing with your system, just use TAI. Don't make UTC a slightly worse version of TAI.
I feel like I'm taking crazy pills.
The idea is exactly to not have a leap hour, UTC is kept completely untouched. Everyone changes their timezone instead, exactly like we already do with daylight savings, except this would happen only once every few thousands of years instead of twice a year.
But again, we already have a time system that does not have leap seconds/minutes/hours. TAI and UTC would become effectively redundant. I don't understand why we need another version of TAI.
On the one hand (like you said before), UTC is what we use for stuff like ordering transactions, which has absolutely nothing to do with the position of the Sun in the Sky.
And on the other hand, we already use timezones to reconcile the rough position of the Sun with our universal clock. Timezones only have resolution of 1 hour (or half in very few places), but looking at how fudged a lot them are, people don't really seem to care. I mean, look at Argentina, which fits almost perfectly in UTC-4 but chooses to use UTC-3 instead. China is even crazier, using a single time in its whole territory which could easily have 3 or 4 different timezones.
Sure, people in Western China may regularly see the sun at midnight, but that's not without controversy. People generally like the sun to be out when they're up.
So I think it makes sense to have both UTC and TAI. If the BIPM just turns UTC into TAI plus a constant offset, then I'd wager they would eventually introduce another system to take the place of the former UTC, with leap seconds, so some people can have that system that reconciles the two clocks if they want it. It's hard to predict the future. But the reasoning in the GCPM resolution [1] seems inherently flawed to me. "recalling that the CGPM at its 26th meeting (2018) ... stated that UTC is the only recommended time scale for international reference" is the core of the problem. TAI should be the ultimate basis. UTC is based on TAI (with leap seconds), and civil time based on UTC.
I always told our new-hires to avoid thinking too deeply about computer timekeeping if they value their sanity.
Civil society around the world has decided on UTC as the basis for time. What’s easier, convincing everyone to switch to TAI or changing the definition of UTC? I would guess it’s the latter.
https://robotsinplainenglish.com/e/2022-11-20-stopwatch-time...
Contrary to this, since at least 2008[0], the POSIX standard (which is just paper not necessarily how real systems worked at that time) has said that "every day shall be accounted for by exactly 86400 seconds." That means that in modern systems using NTP, your Unix timestamps will be off from the expected number of TAI seconds. And yes, it means that a Unix timestamp _can repeat_ on a leap second day.
There's really no perfect way of doing things though. Should Unix time - an integer - represent the number of physical seconds since some epoch moment, or a packed encoding of a "date time" that can be quickly mapped to a calendar day? "The answer is obvious" say both sides simultaneously :^)
EDIT: I know DJB is calling out POSIX's choices in this article, but it seems like his "definition" does diverge from what the count actually meant to a lot of people.
[0] Also: "The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified." https://pubs.opengroup.org/onlinepubs/9699919799.2008edition...
Either way arguably POSIX time is the worst of both worlds, not being either of those. This is one of those cases where middleground compromise is worse than either option. Having datetime be just 15:17 bit structure (date:time_of_day) or more practically just int:int struct, it would be infinitely better than current POSIX time. Or just have it be plain SI seconds since epoch counter would also be better than POSIX time. Or even have both options available. There are so many better options, it is almost baffling how POSIX ended up with the worst possible one
- You can subtract two SI-based timestamps to get a SI-based time difference. This will give you the correct number of nanoseconds.
- You can subtract two UTC-based timestamps to get a UTC-based time difference. This will not give you a number of nanoseconds.
Note that, if you have a list of when leap seconds are, then you can convert between SI-based and UTC-based timestamps which are counted from the epoch; in this way it is possible to get a SI-based time difference from UTC-based timestamps if you need it.
It is not as simple as just subtracting them of course, but if your application is meant to use precise time differences then you can just use SI-based timestamps instead of UTC-based timestamps, so that you can simply subtract them from each other. Programs that need to deal with days and calendars instead, are likely to prefer to use UTC-based timestamps instead.
If you're using TAI, it's more obvious that you have to account for leap seconds in order to convert to a human-readable civil time format (year, month, day, hour, minute, second). You know that you have to incorporate the official leap second list from IANA or some other authority. UTC makes it seem simpler than it actually is, and that's why there are so many problems.
You can always convert from TAI to civil time. You cannot always go the other way.
Most people seem to prefer ignoring leap seconds, pretending they don't exist by "smearing" them across the surrounding day, or even getting rid of them entirely. https://news.ycombinator.com/item?id=33658541 https://news.ycombinator.com/item?id=32226414
The arrogance of programmers who think it is possible to ignore reality to suit them :-)
I suspect the reality is many are unaware of TAI which would be more than 'good enough' and make life much easier for them.
EDIT: Downvotes simply for stating facts and opinions from outside the IT industry hardly prompts useful discussion!
Leap seconds won't even be like the automobile, let alone newspapers or hotdogs, they're a fleeting idea we thought might be good, now we realise it's not good, so bye bye.
There are two "realities" here. TAI is the monotonically increasing "Seconds are the same length and happen in order" clock time that it turns out well suits a lot of human enterprises. The exact details have been worked out pretty well. A Day in TAI is 24 hours of 60 minutes of 60 SI seconds, always, forever.
UT1 is a descendant of "Solar time" now based on the Earth's rotational angle. A Day in UT1 is the full rotation, how long that is in SI seconds varies very slightly and arbitrarily.
UTC wants to have the steady monotonicity of TAI except it wants to match UT1's days exactly, this is not a thing, so the "leap seconds" are conjured to kludge it. This kludge is what's going away, it's not part of "reality" it's a kludge to try to fit a square peg in a round hole and we're giving up the kludge.
It has been a long time since humans worked purely from direct observation of the "solar time" or rotation. Once the clock gets invented, so millennia ago, that's out and humans are measuring (albeit not very precisely at first) what we now call TAI. Giving up leap seconds is us finally accepting that while UT1 is astronomically interesting, it's not actually a sensible basis for day to day living.
Hard disagree!
Allowing ones clocks to gradually drift from the behaviour of the Earth (which regulates our biological lives) is a mess. Once can compare the eventual correction that will be required akin to the shift from the Julian to Gregorian calendar and the problems that caused.
TAI was always there for those who needed it.
This discussion really is highlining the cultural differences between software engineers and other engineering fields.
Planning something “next year” is human-scale. Planning something “next century” is not human-scale because I won’t be alive then.
If we use leap minutes then most people will not see one in their lifetime, compared to everyone seeing multiple leap seconds in their lifetime.
People can't get the regular changes of DST and February 29 correct, and you want them to get a one-off change right?
I'd rather 'inflict' change (semi-)regularly so people at least try to get things right and get some practice, as opposed to a Hail Mary pass/change in some distance future.
In the case of a leap minute, the worst that can happen is that your clock is 1 minute out every couple of centuries. Doesn’t seem so bad and certainly much better than dealing with leap seconds every few years.
We don’t need to constantly rehearse for such an event, we can just do nothing and die without worrying about it.
Every dumb implementation that looked at division by 4 got 2000 right.
Leap seconds are already rare enough that people can't handle them properly. Every time one happens the bug fixes from the last one have been undone.
Granted, this is some 100 times longer than our calendar has lived. And some 10 times longer than any human calendar. So, I suggest we postpone the issue a bit.
Leap seconds allow leap second bugs to be fixed in one generation. Leap minute bugs need cross-generational debugging.
https://gavinhoward.com/2023/02/make-the-leap-second-first-c...
TAI will still be there and needed by folks. UTC is stopping adding leap seconds in the future, not reverting back as if it never had any.
It is irrelevant until it is not: just ask Julius Caesar and Pope Gregory XIII.
> Beyond "what people millennia ago used to do at 7 we do at when the clock says 8" not being a problem […]
The difference of an hour does make a difference, as sleep researchers and chronobiologists keep pointing out every time a discussion on DST comes up (it is not just about the sudden time jump, but also about the actual time):
* https://www.frontiersin.org/articles/10.3389/fphys.2019.0094...
* https://sleepresearchsociety.org/wp-content/uploads/2022/11/...
* https://srbr.org/wp-content/uploads/2018/10/SRBR-Statement-o...
You're refferring to needing to reform the entire calendar but this doesn't make sense in context of me explaining that the calendar itself never needs to be reformed in the first place. That the sun was a few degrees different in the sky for Julius Caesar when a modern clock reads 3 PM in his time is not inherently a problem as Julius Caesar wouldn't have the same norms as you do in terms of what wall time is acceptable for waking/sleeping/eating/working/etc. E.g. 20,000 years from now if a clock reads 3 AM during midday it' not a problem as society will have had 20,000 years to adjust 12 hours vs your referenced calendar reforms that changed everything overnight.
> The difference of an hour does make a difference, as sleep researchers and chronobiologists keep pointing out every time a discussion on DST comes up (it is not just about the sudden time jump, but also about the actual time):
Again, you're missing the forest through the trees - though in two different ways here. The first is that it's a minute over someone's (long) life, so what impact we feel when we change time by an hour twice a year isn't relevant. The second is that society, over 2,000 years, does not need to change timekeeping itself to wake up when the clock says 8 instead of 7. If the change were to happen over a short period then sure, it's not really feasible for society to move up what wall time their breakfast is four times a year or something, but an hour a millenia isn't even something society needs to consciously worry about.
My point is not that we don't have a biological clock, it's that the effect of leap seconds on a human's biological clock are too small to affect it. One of your sources already says it's 15-20 minutes misaligned a day, why are you using it to argue 1 additional minute for your entire life is impactful? On the long term societal scale my point is society won't always agree we should wake up when the wall clock says 7 am. That norm changing shifting ~an hour 2,000 years is not a relevant concern for changing the way we keep time.
Do any of these sleep researchers have anything to say about France using CET instead of GMT even though CET is about an hour off from their natural time? Or Spain being on CET despite being almost another hour off from France?
Furthermore, how long is it going to take for the accumulated leap seconds to add up to a full hour of time? My understanding is that it’s on the order of centuries. If humanity can maintain an industrialized civilization that’s capable of keeping track of leap seconds for that long, most of us won’t even be living on the earth by the time it makes any difference.
Perhaps ask French Sleep Research and Medicine Society (Société Française de Recherche et Médecine du Sommeil):
* https://www.sfrms-sommeil.org
* https://esrs.eu/national-sleep-society/france/
See also Spain:
> Human rhythmicity is subjected to the workings of the internal circadian clock, but it is also influenced by environmental time (mainly the light-dark cycle) and social timing imposed by the official time at our location, as well as by our work schedule. When a misalignment among these times occurs, an internal order impairment appears, which affects our health. Western Spain (GMT+1/+2) and Portugal (GMT0/+1) share similar longitudes (sun time) but have different official times, and thus they provide a “natural experiment” to assess how this discrepancy affects circadian rhythmicity and sleep in people with no work duties (>65 years). Although sleep duration was not affected, the circadian rhythms in the Portuguese were more robust, especially during weekdays, while higher desynchronization tended to occur in the Spaniards. Once official time was corrected by GMT0, meals took place later in Spain than in Portugal, especially as the day progressed, indicating the possible deleterious effect on circadian system robustness when official time is misaligned with its corresponding geographical time zone.
Weeks aren't reality. Timezones aren't reality. Julian/Gregorian calendar months aren't reality. But they are essential.
Calendars, centralised time, and timezones drive coordinated human socialisation and commerce, increasing the wealth of all nations.
Countries have switched timezones so that their "work day" matches another more prosperous country's "work day"
Humans want, and have always wanted, a compromise between their activities, and the unalterable reality of nature. We have "daylight savings time" because if we say "work is between 9AM and 5PM", that allows for the synchronised commerce - you can phone another business at 9AM because you both start work at 9AM, and 9AM = 9AM for both of you. But the reality is that in the winter months, everyone is going to work or leaving work in darkness, with no daylight time for socialisation. So you shift your entire country's (or state's) offset from an absolute clock, to turn "9AM to 5PM" into "8AM to 4PM" without actually stating that, because if businesses started varying their hours, they'd desync completely and you'd never get business done again.
It hasn't been that long since we accepted centralised time, only really since the invention of railways, and especially since the invention of the telegraph. Prior to that, local solar time ruled. Bram Stoker was particulary upset that Ireland was 25 minutes out of alignment with Great Britain (Dublin Mean Time vs Greenwich Mean Time), in his view Ireland was missing out on a lot of trade [0]
I don't think we're going to move to a time source that will slowly desync us from nature. If we liked being desynced from nature, we've have ditched DST by now - we haven't. And we also haven't gone entirely back to nature and made it 9:30 in Dublin when it's 9:55 in London. I think we're going to remain on this middle path - fudging the mixture of atomic time and alignment with solar time - for the rest of our days on this planet.
[0] https://www.thefitzwilliam.com/p/turning-back-the-economic-c...
And we ignore all of those in computer "system" clocks, and track them in a secondary local time layer, quite rightly. We should have handled leap seconds the same way.
For day-to-day operations, we don't need the exact position of the sun in the sky, in fact, with time zones, we can be off by hours and still do business. Using the sun would be inconvenient anyways, as each location would need its own time. So for that, a few seconds is completely negligible.
Not many people care about the precise position of the sun in the sky as seen from an arbitrary location, so there is no real need to skew our overall more useful atomic clocks for this.
Maybe, in a distant future, people will need to update their time zones to catch up with what would be a noticeable shift, big deal...
Computers (and those who programme them) are there to serve humans (with a biology regulated by the Earth), not the other way around!
Terrestrial time don't serve society very well, as it is not very precise, it doesn't serve biology well either, as it is based on some arbitrary meridian instead of your actual location. Biology-compatible times would be in relation to sunrise and sunset, as it is sometimes done.
Each clock would run at a slightly different rate, based on imperfections in the equipment, the altitude of the laboratory and the amount of nearby mass in its vicinity. National clocks would drift, relative to each other, and so would everybody's timestamps. CET would be perhaps +1:00:00.000002 ahead of GMT rather than being exactly +1:00.
You'd have to continually measure and publish this drift in some kind of timezone-to-timezone comparison service, so that people who make network connections across the world don't end up finding that packets appear to arrive before they've been sent (due to National Clock drifts)
It's an interesting thought experiment. But I prefer where all the worlds' labs work together to produce a consensus universal time, and we just add fixed political offsets to it.
Sidenote, "Tai" in the title should be TAI.
TAI to a time people use requires knowledge of all leap seconds as you otherwise end up significantly desynchronized.
And you still need leap seconds list for UTC.
Some say it knows from a NTP server, but that’s the same as needing a database (the server has one)
Unlike with TAI it does not need to know. The time on the wall is leap seconds resolved (ignore for a second how it is done). Whereas TAI keeps ticking onwards without regard of them, UTC has them cleaned up. So if your end result is that you want to show a time in local time with TAI you need to know where all the leap seconds happened. With UTC you do not need to, you will have re-synchronized your clock plenty of times since to some time source which itself has resolved the leap seconds. You do not need NTP for this.
Even if you manually set your time once a year, you will use a reference source that has already dealt with the leap seconds. Since leap seconds are basically hidden historically too (they do not appear) you are good. You can always divide the seconds since 1970 down and you can pinpoint any date in the past without having to do complex leap seconds math.
If your operating system uses UTC, your logging library uses UTC, your SSL cert issuer uses UTC, your TOTP tokens use UTC, your NTP client uses UTC, your e-mail headers use UTC, your string formatter uses UTC, your serialised data parsing libraries use UTC, everyone who sends you data uses UTC, and everyone you send data to wants to receive UTC - why swim against the current?
How do I know this? Because I've tried it. Let me assure you, for every bug you avoid using TAI, you'll experience 500 bugs due to UTC/TAI confusion.
It really doesn't matter if UTC drifts away from solar time by an hour every few thousand years.
Did you ask the person above to explain why they aren't useful?
Since leap seconds don't help for subjective human needs, and they _also_ don't help for computers, science, engineering etc. (if you care deeply about solar noon for some technical reason you should use something that tracks it more precisely than UTC anyway), I can't think of anything they _are_ useful for, except for saving our descendants thousands of years from now from having to change time zones when it drifts far enough to matter, which I think is a speculative and not very compelling reason.
I'd happily change my opinion if I heard a good reason for keeping them, so I object to claiming that this is "hubris".
Just wanted to say I didn't downvote the original comment, I was only trying to guess about how others were perceiving it.
According to the 20. amendment the term of an US president starts at Noon, 20 Januar. Simply noon. The USA seems to interpret it as 12:00 ET and makes it ceremonial inauguration for that time, possibly also the transfer of powers. But solar noon on the steps of the Capitol seems to be at 12:18 ET, I researched back at the last inauguration.
This discrepancy seems to be a great premise for a legal thriller, a political thriller, or sadly for a conspiracy theory. The latter definitely has some fertile ground.
The americans should start using the Washington Monument as a solar clock for this ceremony, imo.
Anyway, that's an explanation of my opinion. Many people will disagree with it.
Why not? Time zones change constantly. Dealing with changing time zones is something we already know how to do easily.
But probably the main argument against getting rid of leap seconds from UTC is that we already have TAI for anyone who wants something like UTC but without the leap seconds. In fact we already have two things that are like UTC but without the leap seconds: there's TAI and there's also GPS time, offset from TAI by 19 seconds. If that's what you want, use TAI. Or use GPS. What's the points of adding a third kind of time that is just like those two but offset by yet another small constant offset?
I tend to think that there's a real use for something like UTC that stays in sync with the Earth's rotation (and thus with the diurnal cycle of day and night) and that if some coterie of bureaucrats turns UTC into another version of TAI/GPS then probably someone else will at some point have to invent another thing to replace UTC and then we'll be roughly back where we started just with extra confusing complexity.
Imagine you want to specify the date and time of an international online meeting. Today you'd probably use UTC for that. But if most of the world were more than 24 hours offset from UTC then using UTC would mean specifying the "wrong" date for the meeting. You probably wouldn't want to do that so instead you'd use whatever new thing has been invented to replace UTC, something that has leap seconds or leap minutes or leap hours (or leap days?) or some other way of staying in sync with the calendar. Leap seconds seems to me like the right granularity: they're small enough to be ignored for most everyday purposes, and frequent enough that programmers can't just pretend they don't happen.
(Sorry for the waffle ... I didn't intend to write that much. I should definitely care less about this seeing as whatever happens I'll be dead long before the shit hits the fan.)
Your example of getting so far off that we have to change _days_ would take several times longer than the distance between the invention of agriculture and now. Honestly, I would be extremely surprised if human civilization survives that long, but even if it does, our descendants can just deal with the problem then. There's no reason to make our lives more difficult _now_ just to deal with this very niche hypothetical scenario.
Downvoting is meant for text that detracts from the conversation. Not as a tool for suppressing well made arguments one disagrees with.
That has to be justified before scrapping something we don't necessarily understand and a lot of programmers are just grateful we have libraries to handle this complexity for us.
Because one cannot ignore nature?
I suspect the vast majority of those programmers who have problems with leap seconds should really be using (and are unaware of) TAI.
Sure we can, in computing make abstractions that ignore nature all the time. As long as there's no issue (or no big issue) with them being out of sync, we're fine.
Besides there are few things natural about how we handle time, those are already big towers of abstractions on top of the movement of celestial bodies that simplify and sidestep a lot of subtleties.
Programmers simply deal with the world as it exists. Every single country uses UTC therefore that is how time must be represented. It is easier to remove leap seconds from UTC than it is to make all countries adopt TAI at the same instant.
The concept of leap seconds can of course be preserved by defining a new time standard that isn’t called “UTC”.
Because leap seconds cause weird gaps or overlaps (depending on how they are happening).
This doesn’t matter for pretty much anyone who doesn’t track/log/act every second all the time in a way where if a second ‘disappears’ or happens twice or takes longer on one day than on another it’s noticeable.
When monitoring or tracking large scale systems, it’s a really irritating problem, which is why TAI is nice and exists in computer land. Also why it’s nice for many scientist types.
For everyone else, something like UTC layered on top is more than good enough. Leap seconds are fine enough there. Same with most timezones, and PDT/PST, etc.
You could even align it with a DST transition in countries that have those where you simply skip one to apply the change.
1)daylight savings should be completely abolished. It just causes confusion.
2)timezones should be completely abolished. They also cause confusion. If you live in California, instead of getting up at say 8am you get up at say 3pm. There is never any confusion with anyone globally about scheduling anything.
3)Months should be the same length. Instead of 12 months of 30, 31, 28 or sometimes 29 days, with a varying number of weeks in each month depending on the year, you have exactly 13 months of 4 weeks each (28 days). 13*28=364 which gives you an extra day "New years day" or "Christmas day" or whatever but that isn't a day of the week. If it's a leap year the day after that Christmas day is "Leap day" and it also isn't a day of the week. Then a particular date is always the same day of the week, months are all 4 weeks, quarters are exactly 3 months and 1 week each and have the same end dates every year etc. Tons of benefits.
Literally the only downside people come up with when I mention it is "yeah but imagine if your birthday is now a Monday, that would SUCK!"
But, err, "am" and "pm" refer to where the sun is in the sky. That's their literal meaning. It's useful information. Timezones are (obviously) a physical thing. Abolishing them to aide the comparatively tiny number of people worldwide who need to schedule a phone call with someone in another country is pretty bonkers IMO.
Furthermore, I don't want to be booking a flight home from Australia to the UK, pick a 9am departure from SYD only to discover it's in the evening.
[1] Notionally. Obviously the sun is not often in the sky in London.
For example I literally have 3 emails in my inbox at the moment that arrived overnight from people in California saying some variation on "I saw a slot in your calendar for xpm PST, is that too late for you in London?".
That's why I support getting rid of leap seconds, but not getting rid of time zones: the number of people who leap seconds helps is very small (possibly zero) since their effect on everyday life is microscopic.
Good luck selling a large swaithe of humanity that Tuesday will turn into Wednesday at some point during their working day.
There will be no more leap seconds after 2035, AFAIK.
The complications are around clocks, UNIX timestamp and NTP, where a steadily and monotonously increasing number would make the most sense, and that's not UTC.
https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-TF.2511-2022...
https://gavinhoward.com/2023/02/make-the-leap-second-first-c...
There are other operating system specifications too, but I also wanted to make one operating system design, and I also wanted to avoid many of the problems with POSIX.
I did not konw that POSIX says that 2100 is a leap year, and clearly that is no good.