> there just can't be any question that not including leap seconds in the count was the right thing to do.
It was a mistake, and no amount of historic excuses can make it a right decision. I never was the right thing to do, neither is it now.
> Users of computers want traditional UTC-style year-month-day etc.
Users don't talk to the kernel, nor with the system libraries. They talk to applications. And by the way, users really don't care about UTC, 99% of the time they want the time their watch says it is. Until that's not enough, and then what they want is an _unambiguous_ moment in time. Anything between those extremes is completely useless.
> To convert from a simple count of seconds to that requires not only significantly more code to be written but some way to know when the leap seconds were.
What exactly solved forcing the duration of the day? Nothing, everything is exactly as complex as it was, but now you have that "fictional" day which is different from what users need. And you still need complex time handling code because there are such niceties as timezones, local calendars, different week conventions, and even time dilation!
> Most of the present discussion isn't about whether the POSIX standard should be a simple count of seconds, but whether the kernel's time base should be.
The mere fact that there's a discussion is a sign that people are not sufficiently aware of past mistakes. We should be raising awareness of this, with the goal of avoiding repeating them. The Kernel should just count time in the most unambiguous way it can, and let applications handle the presentation.
> POSIX doesn't say how anyone has to keep time; it just says how it gets communicated.
An application cannot give the user an unambiguous moment in time if all it can get from POSIX is an ambiguous representation. That is the crux of the matter.