mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Laurent Bercot <ska-dietlibc@skarnet.org>
To: musl@lists.openwall.com
Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files
Date: Sat, 07 Dec 2013 08:52:54 +0000	[thread overview]
Message-ID: <52A2E1E6.6030708@skarnet.org> (raw)
In-Reply-To: <20131207023114.GK24286@brightrain.aerifal.cx>


> What I'm missing is the benefit. The only benefit I can see to using
> TAI-10 is that you're synchronizing with your chosen clock source over
> years/decades with no discontinuity. If you're willing to accept a
> discontinuity every few years, why not just use plain POSIX time and
> apply the new difference between TAI-10 and POSIX time when rebooting?

  You don't choose when a leap second happens. To provide accurate time at
every instant your machine is up, you would have to schedule your
downtime right around a leap second. That's obviously not possible. My
suggestion allows you to choose and plan your discontinuity, most
probably merging it with some other discontinuity that will happen
anyway, while providing accurate time at every moment.


> I think this is an area where you'll find you're coming from a
> fundamentally different philosophy than most of the musl folks. The
> way I interpret your position is that using TAI-10 is only suitable
> for managed desktop/server systems, not any other kind of use where
> there's no system operator who's aware of leap second announcements
> and capable of doing manual upgrasdes. (And having system scripts kill
> and restart processes behind your back to do this for you is even
> worse; that's akin to the way Windows automatically reboots behind
> your back, and users hate it.)

  - Users hate it when Windows reboots behind their backs because it
obnoxiously gets in their way and disrupts their workflow. It's an obvious
loss of quality of service. Restarting a Unix process has nothing to do
with that. Even rebooting a whole Unix machine has nothing to do with that
if it's correctly planned.
  - Even embedded systems have firmware upgrades, and most embedded devices
automatically download the new firmware and switch to it the next time the
user powercycles the machine. I challenge the belief that a system without
any kind of operator is going to have a 3 years uptime. (And if it does,
it probably doesn't need to measure Earth time accurately.)
  - If there's such a demand for it, I can provide an implementation where you
don't even have to restart a process when the leap second table changes. It
will just be expensive at run-time (perform some kind of test whenever the
table is accessed, or simply open/read/close the file for every access). I
will ask for a musl compilation option to disable it, though, because I
believe it's useless and a waste of resources.


> 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".

  It probably becomes a matter of religion at this point. What is a second ?
is it Evil if a second isn't always the same duration ? Is it Evil to pretend
that some operation lasted 5 seconds when it actually was a bit more by the
usual definition of a second ?
  Until kernels perform leap smearing or provide CLOCK_UTS, and we manage to
coerce computers into using our imperfect, changing, human idea of time without
choking (my religion considers this as torture!), though, TAI-10 is the only
way to achieve this goal in practice.


> 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.

  I agree that ntpd is a prime example of bad design in about every way, but
I blame POSIX more for forcing computers to align system time with human time
in the first place. :)

-- 
  Laurent



  parent reply	other threads:[~2013-12-07  8:52 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-26 18:53 [PATCH] " Laurent Bercot
2013-11-26 18:59 ` Laurent Bercot
2013-11-26 23:32 ` Rich Felker
2013-11-27  1:06   ` Rich Felker
2013-11-27  4:10   ` Laurent Bercot
2013-11-27  4:25     ` Rich Felker
2013-11-27  5:53       ` Laurent Bercot
2013-11-27 18:43         ` Szabolcs Nagy
2013-11-27 20:33           ` Laurent Bercot
2013-12-05  1:13             ` [PATCHv2] " Laurent Bercot
2013-12-05  5:18               ` Szabolcs Nagy
2013-12-05  8:58                 ` Laurent Bercot
2013-12-05 14:21                   ` Szabolcs Nagy
2013-12-05 14:43               ` Rich Felker
2013-12-05 16:31                 ` Laurent Bercot
2013-12-05 16:40                   ` Rich Felker
2013-12-06  0:36                     ` Laurent Bercot
2013-12-06  0:45                       ` Rich Felker
2013-12-06  1:15                         ` Laurent Bercot
2013-12-06  5:31                           ` Szabolcs Nagy
2013-12-06 10:48                             ` Laurent Bercot
2013-12-06 11:38                               ` Raphael Cohn
2013-12-06 23:29                                 ` Laurent Bercot
2013-12-07  2:31                                   ` Rich Felker
2013-12-07  4:02                                     ` Szabolcs Nagy
2013-12-07  8:52                                     ` Laurent Bercot [this message]
2013-12-06  6:29                           ` Rich Felker
2013-12-06 10:37                             ` Laurent Bercot
2013-12-06 12:50                               ` Rich Felker
2013-12-06 13:27                                 ` Szabolcs Nagy
2013-12-06 15:48                                   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52A2E1E6.6030708@skarnet.org \
    --to=ska-dietlibc@skarnet.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).