Hacker News new | past | comments | ask | show | jobs | submit login

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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: