[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52A12548.80508@skarnet.org>
Date: Fri, 06 Dec 2013 01:15:52 +0000
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files
> Regarding the unfortunate coupling of timezone and leapsecond data
> into a single file, do the zoneinfo files with leapseconds have their
> timezone transition times stored in POSIX time or TAI?
TAI-10 (the 10 seconds offset is so it's the same as POSIX time
before 1972). As I said, it's the only behaviour that makes sense:
we're counting a number of seconds and we want it to be unambiguous.
POSIX time would create an ambiguity for the very moment when a leap
second happens, which defeats the purpose.
> It seems really inconsistent to me that someone who's pedantic enough
> to care about leap seconds wouldn't care about having to "reboot" (I
> use this term loosely) their servers/daemons when a new one is
> announced. If you're ok with that discontinuity what's wrong with just
> losing the leap second?
Leap seconds are announced in advance; it's easy to plan a "reboot"
over a 6-month (or larger) period before the actual leap second happens.
On the other hand, no planning will prevent the kernel from crashing,
make from getting confused, CLOCK_REALTIME-based event loops from failing
when the system clock hiccups under their feet.
Locking and an advanced updating system to the leap second table could
be designed, so that long-lived processes don't even have to restart when
a new leap second is announced. But frankly, it just doesn't seem worth the
trouble. Restarting a process is easy; people who need high availability
usually have several instances of the service and can restart them one by
one.
> At the very least they would have some overhead determining that
> leapseconds aren't in use.
Indeed, one test at executable start. :)
Do you have any idea what form this test would take, if we're opting
away from TZ ?
--
Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
