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]
Date:	Sun, 4 Jan 2009 03:13:11 -0800 (PST)
From:	david@...g.hm
To:	David Newall <davidn@...idnewall.com>
cc:	Kyle Moffett <kyle@...fetthome.net>,
	Ben Goodger <goodgerster@...il.com>,
	Robert Hancock <hancockr@...w.ca>,
	linux-kernel@...r.kernel.org, linasvepstas@...il.com,
	"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 Sun, 4 Jan 2009, David Newall wrote:

> Kyle Moffett wrote:
>> Actually, "diddling the clock" is really the only valid solution to
>> the leap-second problem.  The leap-second is such a fine adjustment
>> that it is actually affected by random "noise" introduced into the
>> solar-system from the chaotic gravitational interactions of the
>> planets with each other.  It's impossible to reliably calculate which
>> future years will have leap seconds, and in which direction they will
>> occur.
>>
>
> You're confusing the system of keeping time with those characteristics
> of the real-world which it represents.  They are, in fact, two different
> things, hence we regularly adjust the system.  Now in the case of UNIX
> and derivatives, the system records the number of seconds since an
> arbitrary point-in-time, and presents a "wall time" (i.e. the time
> displayed by the clock on the wall) using, amongst other things, a set
> of adjustment rules codified by a zoneinfo file.  The number of second
> between 1 minute to- and midnight-ending 31 December is 61.  If Linux
> does not reflect that it is wrong and must be fixed.  If it isn't fixed
> we will increasingly discover a discrepancy between time-data that
> originates on Linux versus other, correct systems.
>
> I don't understand why such a simple thing was unnecessarily
> complicated.  And causing crashes!  Ha ha ha or what?  A simple addition
> to zoneinfo was (and still is) all that is required.

so are you saying that other 'correct' OS's have patches issued every time 
a leap second is declared so that they have an in-kernel table of them to 
use to calculate the correct time?

what about systems that have hit end of life? what about systems that 
users don't want to have to reboot to install a new kernel for a 1 second 
shift (which NTP will take care of as far as they are concerned anyway)

when the daylight savings time definitions change all the vendors had to 
issue patches, I saw those. I didn't see any patches for the leap second, 
so how do these other systems deal with it?

David Lang
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ