linux-kernel - Re: Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090106025125.GB28431@mail.local.tull.net>
Date:	Tue, 6 Jan 2009 13:51:25 +1100
From:	Nick Andrew <nick@...k-andrew.net>
To:	David Newall <davidn@...idnewall.com>
Cc:	Linas Vepstas <linasvepstas@...il.com>, david@...g.hm,
	Kyle Moffett <kyle@...fetthome.net>,
	Ben Goodger <goodgerster@...il.com>,
	Robert Hancock <hancockr@...w.ca>,
	linux-kernel@...r.kernel.org,
	"Jeffrey J. Kosowsky" <jeff@...owsky.org>,
	MentalMooMan <slashdot@...eshallam.info>,
	Travis Crump <pretzalz@...hhouse.org>, burdell@...ntheinter.net
Subject: Re: 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:

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.

Nick.
-- 
PGP Key ID = 0x418487E7                      http://www.nick-andrew.net/
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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/