[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.