[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8752a8760901022237r75d408b3i74c703c8ac2d4597@mail.gmail.com>
Date: Sat, 3 Jan 2009 06:37:38 +0000
From: "Ben Goodger" <goodgerster@...il.com>
To: "David Newall" <davidn@...idnewall.com>
Cc: "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
2009/1/3 David Newall <davidn@...idnewall.com>:
> Robert Hancock wrote:
>> Diego Calleja wrote:
>>> How could I create a test case that reproduces what ntp does? Just add
>>> a second?
>>
>> I'd think that setting the clock to just before midnight on Dec.31 and
>> using the adjtimex syscall to set the TIME_INS state on the clock,
>> then waiting until midnight rolls around would be a reasonable test..
>
> I don't understand this idea, nor the patch for the problem. I don't
> see why adding a leap second would impact the kernel in any way.
> Shouldn't this be a simple zoneinfo change, whereby the last two seconds
> of the year (in each timezone) both map to 31dec2008 23:59:59? That's
> the way the change has worked in the real world. Why would ntp or the
> kernel be involved?
Actually, the change has worked in the real world with the
introduction of a new second named 23:59:60, or else ignoring the leap
second entirely and correcting the clock (or not) later...
--
Benjamin Goodger
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/S/M/B d- s++:-- a18 c++$ UL>+++ P--- L++>+++ E- W+++$ N--- K? w---
O? M- V? PS+(++) PE-() Y+ PGP+ t 5? X-- R- !tv() b+++>++++ DI+++ D+ G
e>++++ h! !r*(-) y
------END GEEK CODE BLOCK------
--
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