> The problem is that posix needs the conversion between 'posix time' (seconds since 1970) and the split out year/month/day/hour/minute/second format to work for the future as well.
> Given that we don't know when there will be leap seconds in the future, this conversion is impossible if we want to take leap seconds into account.
The conversion is impossible anyway. We don't know what the calendar will look like in the future. That isn't a problem that can be solved by any means.
As always, the problem can at least be made easier by using the right data structure.
Counting time as just "seconds since epoch" is like, really convenient, and by convenient I mean lazy. It may have even been excusable when computers had kilobytes of RAM and if they had hard disks at all, it wasn't more than a megabyte. When "assembly" was high-level programming.
But now that we have infinite disk, processors that are idling most of the time they aren't rendering 3d video, and programming languages which almost don't suck, we could stand to use richer representations of dates that include the semantic concepts people use when talking about time, like "years" and "days" and "hours". You don't need to know how many leap seconds -- or even leap days -- are between 2021-07-01 and 2022-07-02 to say that one is a year and a day after the other.
There was a time and a place for "GOTO"s; there still is, just much less often than back when that was your only real option for flow control. Likewise, the time for storing dates and times as seconds since Jan 1 1970 was much closer to that date than today.
That is different type of future. For a while leap seconds would come at a rate of around one leap second every 18 months. It is safe to say that the current calendar will be with us the next couple of years.
Long term, who knows. But we would like to be able to do date calculations a couple of years into future.
> Long term, who knows. But we would like to be able to do date calculations a couple of years into future.
On the fairly safe assumption that you don't care about being off by a few seconds, leap seconds aren't a factor there. Assuming one leap second every month (!), your computed date two years out will be off by less than half a minute. No one will ever even notice; the entities that consume dates in calendar format -- people -- aren't capable of meeting time tolerances that tight.
If you need to coordinate something down to the millisecond, calendar dates aren't for you.
That's the point, if you need to coordinate things down to the millisecond, leap seconds are incredibly harmful, and if you don't, they are irrelevant.
Timezones and timezone offsets do change more frequently though, and sometimes withot any heads up. Being able to correctly format future dates is only possible for UTC, even with leap seconds.
> Given that we don't know when there will be leap seconds in the future, this conversion is impossible if we want to take leap seconds into account.
The conversion is impossible anyway. We don't know what the calendar will look like in the future. That isn't a problem that can be solved by any means.