Hacker News Reader

Comment by phicoh | Hacker News Reader

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 imposible if we want to take leap seconds into account.

So the solution is to either ignore leap seconds (as posix currently does) or have a regular rate of leap seconds (just like leap years). Unfortunately, the rotation of the earth is are not regular enough for a fix rate.

At the scale of a human life, leap seconds are completely irrelevant if you want to know the position of the sun.

So it is bizar that our civil time has leap seconds. Looking back, that seems to be a historical mistake.

View on HN

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

> if you need to coordinate things down to the millisecond

If this coordination needs to happen > 6 months in the future, then UTC is the wrong time standard to use. Use TAI.

There is no use case for UTC.

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.

Reply on news.ycombinator.com