[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Dec 2013 05:02:06 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files
* Rich Felker <dalias@...ifal.cx> [2013-12-06 21:31:14 -0500]:
> On Fri, Dec 06, 2013 at 11:29:33PM +0000, Laurent Bercot wrote:
> > On 06/12/2013 11:38, Raphael Cohn wrote:
> > >Date and time match has been got wrong in every system
> > >(...)
> > >Personally, I think apps should just use a monotonic source of seconds
> > > from an epoch, and use a well-developed third party lib dedicated to
> > > the problem if they need date math (eg Joda time in Java).
> >
> > I absolutely agree with you on the first part. I disagree on the second
> > part. Dealing with time shouldn't be a burden on the application - devs
> > have other things to think about, and experience shows that most of them
> > won't care, they'll just use the primitives provided by the system. So,
> > the system should do the right thing, i.e. provide something that works
> > no matter how applications are using it. Here, it means providing a
> > linear CLOCK_REALTIME, because people use it as if it were CLOCK_MONOTONIC.
>
> If that's your only goal, it's easily achieved without storing TAI-10
> in the CLOCK_REALTIME clock, assuming by "linear" you just mean
> "monotonic, continuous, and accurate within the margin of measurement
> error". Discontinuous jumps and non-monotonicity in CLOCK_REALTIME
> were a monstrosity invented by the NTPD folks in their implementation
> for mapping TAI onto POSIX time, not any fundamental requirement.
it's worse than that, the proposed solution does put a burden on userspace
(unix time can no longer be used to calculate or represent dates)
while with the standard 1 day == 86400 s apps and admins do not even need
to know about leapseconds (only the time daemon and kernel)
about linearity:
if you only smooth out a leapsecond in the month it was inserted, then a
unix second would be about 30*86400/(30*86400+1)-1 = -0.386 ppm (= 386ns)
shorter than a SI second in that month, by comparision (according to the
ntp clock quality faq) the oscillator used by most hw usually have more
than 1 ppm frequency error and it can change 1 ppm/C when heated up if no
temperature correction is done, so apps already have to deal with larger
errors and the smoothing logic is in the kernel/ntpd they just don't apply
it to leapseconds
this will work for more than 1000 years (earth rotation drift is <12s/year)
and somewhere during that time leapseconds will be abolished and it stops
being a problem..
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.
