[beeforpork]

These are 'interesting', but ultimately naive ideas, and the headline is presumptuous.

Instead, the world needs agreement. And, wow!, an agreement among countries to simplify time keeping is an achievement!

We do not need a more complex POSIX time spec, but we need to cope with billions of written lines of code from the past that use the existing API. We need that API to be as stable as possible to reduce complexity. We need to see that no changes are needed to existing code.

We need to reduce complexity, e.g., by removing an irregular, unpredictable drift between TAI and UTC.

We do not need to rewrite legacy code to use a shiny new API, but we need to make sure that legacy code will not break, because we do not know, unfortunately, were all that code hides.

[zowie_vd]

Thank you for your opinions. The point of my proposal was to keep the API entirely backwards compatible, so rewrites would not be necessary. The important part is the "Legacy Unix Time" part. The other two definitions I provided simply serve that definition. I hope that you will agree that this is not that much more complicated.

Notably I don't disagree with the idea of abolishing leap seconds, but I also don't think it's entirely agreeable to have the world's timekeeping standards changed solely because of engineering needs with regards to Unix time. In my opinion it's somewhat silly to have the timekeeping standard of the world changed because someone at Bell labs made an unfortunate design decision regarding Unix time, rather than changing Unix time itself.

[beeforpork]

> I hope that you will agree that this is not that much more complicated.

Sorry, but I do not agree. The current Unix time API is good enough. Especially with the leap seconds gone. We need no more complication by innovation here.

Any extensions inevitable lead to a lot of people starting to use those additional APIs, others trying to fix old code to use new APIs, and a few will start religiously fighting for the use of the new 'right' API. Software that handles time would be more diverse. And you will never live to see that old API gone anyway, because we don't know where it hides, so in the future, we would have to deal with bugs in the (mis)usage of more APIs.

> In my opinion it's somewhat silly to have the timekeeping standard of the world changed because someone at Bell labs made an unfortunate design decision regarding Unix time, rather than changing Unix time itself.

Well, maybe it is silly. But that's really irrelevant. Don't be stubborn to insist on API changes/extensions, because you think a past decision was wrong. You can't change reality anyway: the vastly bigger problem is changing Unix time, because code is written and is running in critical systems.

And because leap seconds were inserted manually anyway, we already have a solution that works: don't insert any more leap second manually.

Also note that the danger was to do something new: remove a second. That is a very dangerous experiment. E.g., the German DCF77 cannot even announce that (I think the UK and US time signals can, IIRC -- I am not sure about Japan and the other time signals). Of course you could start to postulate we need a new time signal format in Germany (and effectively half of Europe) to fix that, but that is just a much more dangerous approach.