Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 06 Jan 2009 12:29:47 +1030 | From | David Newall <> | Subject | Re: Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009 |
| |
Nick Andrew wrote: > I can sympathise with the opinion that linux should be able to accurately > distinguish xx:59:60 when a leap second is added (or the missing :59 when > one is subtracted) but not at the expense of making a day which is not > 86400 seconds long. >
Some days are not 86400 seconds long. That's a fact and regardless of how inconvenient it is, we have to live with it. Some years don't have 365 days; some months don't have 30 days; some Februaries don' have 28 days; and now, some days don't have 86400 seconds. What's the point in fighting this?
If you want to know the days between two times, dividing by 86400 doesn't cut it.
> Arguably the kernel's responsibility should be to keep track of the > most fundamental representation of time possible for a machine (that's > probably TAI) and it is a userspace responsibility to map from that > value to other time standards including UTC, using control files > which are updated as leap seconds are declared.
We have this already; zoneinfo
> Just so long as the > existing behaviour of time() which doesn't recognise leap seconds > is preserved.
I haven't been able to find this Annex B that Alan talked of, so I can only go by the man page, which states, simply and explicitly, that time() returns seconds since Epoch, and also that Epoch is start of January 1 1970. To my mind, time *does* recognise leap seconds.
| ![\](/images/icornerr.gif) |