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