[PeterisP]

Can someone comment on the practical usefulness of having UTC stay strictly synchronized with the rotation of the Earth?

Intuitively it should be synchronized, but giving it more thought it is not entirely obvious why; e.g. my current local time zone is more than half an hour off of local solar time, and that isn't really a practical problem, so if UTC would be, say, five minutes off of actual solar time in Greenwich, what issues does it cause for people? Astronomy would be using specific time systems and/or adjustments anyway.

[gerikson]

I see leap seconds as regulatory capture by astronomers :D Basically it's convenient for them to have civil time (UTC) never more than 0.5s from UT1.

[masklinn]

Astronomers don’t care, they already need like 5 different clocks.

Also the allowable variance between UTC and ut1 is 0.9.

[PeterisP]

Exactly - and if astronomers don't care, what other reasons are there to require accurate synchronization of UTC (and civil time) with earth's rotation?

[lostmsu]

Considering the rate of progress, timestamps might need to be replaced with reference-invariant coordinates.

[moffkalast]

Or one clock that can switch between 5 different times.

[masklinn]

I didn't necessarily mean 5 different timekeeping devices (though that would probably be more convenient in many cases), rather than an astronomer needs to keep track of multiple different "times" concurrently.

[michaelt]

> what issues does it cause for people?

Five minutes - no problem at all.

If the offset rose to 60 minutes, I know people complain bitterly twice a year when we change the clocks by an hour and they lose an hour of light for sports in the evening, or lose an hour of sleep. But with leapseconds taking ~0.5 seconds a year, that won't be a problem for a few thousand years.

[yakubin]

But that’s caused by changing the clock all the time, the opposite of what PeterisP proposed. When it comes to constant offsets[1], there are countries whose political time zones are shifted from their geographical time zones by 1h (Spain, Iceland) or even 2h (Western China). It doesn’t seem to be causing problems.

[1]: Because allowing the time to drift microscopically from human perception is indistinguishable from not changing it, only that after a sufficiently long time you live in a time zone shifted by a constant, only there was never really a big event to shift it. It’s like getting old - you don’t notice it, until it’s already happened.

[fanf2]

Around the time TAI drifts an hour from UT1, the current definition of UTC will require several leap seconds each year to keep in sync. So there isn’t much point saying that we have to keep the current definition of UTC to avoid leap hours, because the current definition of UTC will not work that long. https://www.ucolick.org/%7Esla/leapsecs/dutc.html

[prennert]

60mins offset is fine¹. We have this all the time with timezones. But imagine investigating and outage or scheduling an automated event when you have to make sure and communicate with non-technical folks that your graph / setting etc is off by 5:23 minutes.

The OP proposal does say UTC should be used when representing time to end users, but in practice there is going to be blurry lines.

¹TBH, still confusing enough to introduce quite a bit of friction when comparing graphs etc for outages.

[zowie_vd]

I don't think there is a practical need for UTC to be synchronized with the rotation of the Earth for a long time, because although the error accumulates, it only accumulates very slowly. That being said, it's unclear how people would solve the problems that will arise once that long time has passed. In any case, although it's probably too late for leap seconds, untying the definition of Unix time from UTC would allow astronomers to decide with more freedom what the future of UTC is going to be.

[WorldMaker]

> That being said, it's unclear how people would solve the problems that will arise once that long time has passed.

I feel like we should be able to easily "bundle" leap seconds into existing leap days on leap years. Make February 29th just some random number of seconds shorter or longer than, say, February 28th. Most people feel February 29ths are weird anyway, few people would probably notice when they have strange amounts of seconds in their final hour. Some software might hate it if Feb 29 23:59:56 rolls over to Mar 1 00:00:00 or much more rarely there's a Feb 29 23:59:62 (or using the existing Unix time "smearing" technique, some Feb 29 you get three or more Feb 29 23:59:59 timestamps in a row), but other than that it would 1) be on a predictable day, and 2) a day that's already a weird every 4 years except every 400 outlier that's already expected to be an edge case.