[fanf2]

Leap seconds are in the process of being abolished. The ITU-R confirmed their part of the agreement at the world radiocommunication conference last year (the ITU-R’s triennial treaty update); the next stage is the CGPM in 2026 (the BIPM’s triennial treaty update).

[arijun]

Will there be another solution for the desynchronization of SI days and solar days? It looks like there’s been about 25 seconds difference in the past 30 years or so.

[eequah9L]

An option if it gets way off would be to just express it as TZ shift. Current rate seems to be about a second every two years, so we have some hundreds of years before we need to even shift by 15 minutes. An amount of divergence that I suspect would not really be even noticeable, especially as it develops over hundreds of years. The TZ code is used widely and regularly and systems tend to know how to handle it. Leap seconds are always a bit of an adventure from what I understand. (I'm not a sysadmin, so I don't know the details.)

Like -- I don't know, but is it actually important that the solar day is tied to "wall clock day" so snugly? So what if it's a couple minutes off...?

[naniwaduni]

> Like -- I don't know, but is it actually important that the solar day is tied to "wall clock day" so snugly? So what if it's a couple minutes off...?

Even when you're assigned a correct hour-aligned time zone, you'll be off by an average of 15 minutes! Wall clock time just fundamentally has never been precise enough for leap seconds to solve a problem, by two orders of magnitude.

[brookst]

A 15 minute shift once every hundred years would wreak havoc on all of the software built when the shift was too far away to worry about.

Better to design in the requirement for all software to support these shifts, like a random 10 minute shift every day. That way nobody will write software that doesn’t support the shift.

[toast0]

Timezone aware code already has to process 15 minute timezones, IIRC; India is on a 30 minute timezone.

Some timezone changes are well published before the change and others are published after, and software has to pick up the pieces.

I'd imagine a 15 minute jump to recenter zones would be published with at least as much notice as changes to DST rules.

[hermitdev]

AFAICT from looking at the source for the tz database [0], it's capable of handling UTC offsets at least to a second level, if not fractional seconds.

[0] https://github.com/eggert/tz

[fanf2]

ISO 8601 and other display standards for timezones only support one minute resolution.

[fanf2]

UT1 is available from the IERS if you need it.

[sed3]

We can move timezone after 3000 years, when difference will be 1 hour and noticeable.

[ynik]

Yep. Timezone definitions already change regularly due to governments messing around with time; so software is already set up to handle this case.

Though I wonder what happens with the international dateline -- would it shift around the world, or would the UTC offsets get larger and larger? I imagine the latter would eventually also result in software issues when the UTC offset starts exceeding 24h.

[fanf2]

There are moves to abolish DST and I suspect that after that happens timezones will ossify, which will make it difficult to use them to compensate for a large DUT1. And after 1000 years of gradually shifting daylight, people will probably be used to noon being a bit late and may well prefer it.

[smegger001]

In a thousand years it is quiet possible there will be sizable enough population off of earth that trying to align time with the variable rotation of the earth will be seen as pointless Terracentrism

[MichaelZuo]

Maybe 1500 years and 30 min.

[martin_a]

I've created a ticket in the backlog for this!

[tomthe]

Maybe 750 years and 15 min.

[crote]

Which leads to another interesting question: are we going to sync up UTC and TAI, or do we just have to live with a completely arbitrary several-second offset for all eternity?