7 ms·
You're right. It should say: Unix time is the number of seconds since epoch, not counting leap seconds.
by kijinbear 15y ago
You're right. It should say: Unix time is the number of seconds since epoch, not counting leap seconds.
- bluedanieru 15y agoAny idea why it was done this way? It seems like counting leap seconds belongs in the same layer as sorting out timezones, i.e. not here.
- thristian 15y agoBecause people working with timestamps like to write code that says things like: // schedule another run for tomorrow schedule_event(now() + 86400) ...which doesn't actually work when leap-seconds are involved (things start to drift by a second). If you specify that leap seconds get replayed, it works.
- shaggyfrog 15y agoAn article previously linked on Hacker News goes into leap seconds in much greater detail and is a good read: http://cacm.acm.org/magazines/2011/5/107699-the-one-second-war/fulltext http://cacm.acm.org/magazines/2011/5/107699-the-one-second-w...
- bluedanieru 15y agoStrange then that we'd scold a developer for assuming the number of hours in a day, or the timezone, or whatever, but not for using Unix time as an absolute time, when in fact it is not an absolute time at all and even caters to the same error in thought.
- derobert 15y agoPossibly its a historical accident: UNIX was released before the first leap second, and before anyone could have known they were needed (back when seconds were defined in terms of Earth's movement). Around its release time, the definition of the second was switched (making leap seconds potentially needed). Maybe by the time anyone realized, switching from UTC to TAI would have been too painful? Not to mention that you can't know the UTC-TAI offset more than a few months into the future. We can not predict which years will have leap seconds inserted. Unix timestamps do not handle leap seconds well at all. Obvious things like t₂-t₁ fail to provide the number of seconds between t₂ and t₁.