[lkml]   [2009]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009
On Tue, Jan 06, 2009 at 12:29:47PM +1030, David Newall wrote:
> 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.

Sorry, but you're wrong - in the context of time_t, every day is 86400
seconds long. man 2 time says so clearly in the notes:

POSIX.1 defines seconds since the Epoch as a value to be interpreted as the number of sec‐
onds between a specified time and the Epoch, according to a formula for conversion from
UTC equivalent to conversion on the naive basis that leap seconds are ignored and all
years divisible by 4 are leap years. This value is not the same as the actual number of
seconds between the time and the Epoch, because of leap seconds and because clocks are not
required to be synchronized to a standard reference.

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

I'm not fighting this - the real world has all these issues but the
world of time_t does not. You want to redefine time_t to include all
the leap seconds that were already added (34) or perhaps only the
future ones; either approach is a disaster. It's unreasonable to change
the semantics of something as fundamental as time_t when so much code
depends on those semantics.

Instead, define a new timebase which counts time predictably and
unambiguously then a set of mappings to derived time values like
time_t, UTC and local time.

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

Please read the NOTES section, which clarifies what "seconds since
the Epoch" means.

PGP Key ID = 0x418487E7
PGP Key fingerprint = B3ED 6894 8E49 1770 C24A 67E3 6266 6EB9 4184 87E7
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-01-06 03:55    [W:0.233 / U:1.008 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site