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]

Date:	Sun, 4 Jan 2009 04:00:16 -0500
From:	"Kyle Moffett" <kyle@...fetthome.net>
To:	"David Newall" <davidn@...idnewall.com>
Cc:	"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, Jan 4, 2009 at 3:43 AM, David Newall <davidn@...idnewall.com> wrote:
> Ben Goodger wrote:
>> 2009/1/3 David Newall <davidn@...idnewall.com>:
>> Actually, the change has worked in the real world with the
>> introduction of a new second named 23:59:60
>
> Fine.  However you want to describe that last second is immaterial.  The
> point is that diddling the clock is not a true solution.  Take seconds
> since epoch for January 1 and subtract the seconds since epoch since the
> previous day and if the result isn't 86401 it's wrong.  Is Linux wrong?
> (I gather it is.)

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.

Our calendar year is pretty damn close after we have accounted for the
standard leap-year algorithm, but that algorithm cannot be modified
without breaking a great number of existing date-time systems.  The
proper answer (currently implemented in systems all over the world)
coordinates atomic-clock systems across the world with the measured
traversal of the earth (as referenced against the sun and the stars).
If the clocks are slightly "ahead" of where they should be, a leap
second is scheduled to be inserted, and if they're behind, a second is
removed.  The flow-of-time is then adjusted for the last minute so
that it runs either 101.6959% of the normal rate (59-second minute) or
98.3606% of the normal rate (61-second minute).

The effective end result is that time actually flows smoothly but the
assumed date of the epoch is adjusted slightly relative to real time
based on subtle fluctuations of the earth's rotation and orbit.

Cheers,
Kyle Moffett
--
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/