lkml.org 
[lkml]   [2009]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009
2009/1/5 David Newall <davidn@davidnewall.com>:

> Zoneinfo files cater for leap seconds.

As has been (repeatedly) pointed out, the leap seconds
only apply to UTC, so there is no way, given UTC, to
use a zoneinfo file to twiddle UTC.

Your argument *might* work if the kernel maintained
TEI instead of UTC. Then there could, in principle, be
a zoneinfo file that converted from TEI to UTC (by
adding 24 seconds to TEI).

However, this requires converting the kernel to track
TEI instead of UTC, and reviewing all sorts of code
in the kernel, glibc, ntp, and myriads of other libraries
to figure out what's affected and whats not. As well
as figuring out how to twiddle zoneinfo files so that
they're backwards/forwards compatible with the
timekeeping change, so that users aren't screwed
when they put new kernels on old distros, or new
zonefiles on old kernels.

This is a fairly big chunk of work, requiring coordination
between lots of different parties.

> If you know in advance, you can update zoneinfo files with multiple leap
> seconds.

Heh. You miss the point. The whole point of leap seconds
is that they're unknowable in advance. You only know if they
already happened, or seem likely to happen real soon now.
The previously cited wikipedia article reviews this nicely.

--linas

p.s. Yes, you could say I'm coming around to your point
of view. If you had said, from the begining, something
like "the kernel should keep TEI instead of UTC, and
compute UTC in user-space from the TEI time", then
you might have met a lot less resistance. But that's not
how your argument came across.


\
 
 \ /
  Last update: 2009-01-06 00:07    [from the cache]
©2003-2011 Jasper Spaans