[ntp:questions] Leap second to be introduced in June
Jochen.Bern at LINworks.de
Fri Jan 16 10:57:50 UTC 2015
On 01/16/2015 05:41 AM, Chris Adams wrote:
> I think one problem with OS clocks in TAI is that counting it correctly
> requires active/on-going maintenance at unknownable intervals for all
> systems that use any form of timestamps (including for example anything
> that uses network file systems).
Actually, no, it's the very *reason* to try and use TAI for the baseline
that a stable oscillator and a simple counter suffice to do *that*
correctly, even (to an extent) all the way through the lifetime of the
hardware and its users and in absence of external sync/data sources.
The problem arises the moment you want to convert to UTC (or *any*
timescale trying to approximate Earth's rotation), and it is
conceptually unavoidable because the planet is neither a precise
oscillator, nor does it have USB ports to provide our devices with "true
data" directly. (And because the long-term development of the Earth-Moon
system leads to Earth's rotation getting gravitationally locked to the
Moon like the Moon's already is to Earth, at which point a day on Earth
will be as long as what, 40 or 50 of our current days?)
While I'm ranting, and because you mentioned the problems of
distributing what essentially is the (current) leap seconds table:
We all know that the current NTP protocol leans toward UTC, and doesn't
address any leap seconds except the one that might be at hand right now.
In recent posts to this list, I've read about plans for an NTPng that
allows for different timescales, but still suggests that the leap second
table be distributed, where necessary, through other, general-purpose
protocols like FTP and HTTP.
I'm running platforms consisting of hardware that ranges from servers
(with a general-purpose OS) to switches to "simplistic" devices like
UPSes or environment sensors. I see the latter's firmware doing SNTP
(why would you ever need to configure *two* servers, or a custom
interval??) and claiming it's proper NTP in the admin UI. I remember
them not having any trace of DST support for Germany until after an
EU-coordinated DST came into existence. On the other hand, I see server
OSes which *claim* that timezones can be chosen at will and thus should
be entirely irrelevant to system administration - but actually *still*
have one designated one, e.g., to use in their crontabs. And, of course,
I'm the one who would need to convince the CISO that device X needs to
talk not just NTP but *HTTP* (oh my God, ever heard of drive-by
downloads?!?) to the outside.
Read my lips: Unless NTPng *includes* features like delivery of the leap
second table and announcement of a "preferred" timezone (which
information one would inject into the platform's outside-facing NTP
servers by manual config, of course), so that developers of whatever
firmware see that the data's right in the reply packets they already
have in RAM, syncing time across entire platforms *WILL* remain a
problem because there *ALWAYS WILL* be lots of "broken" clients getting
into the way of a solution.
> Also, you can't properly represent future timestamps (necessary for some
> things) as seconds since an epoch, and that's pretty widely used. By
> that I mean that the number of seconds between 2015-06-30 23:59:00 and
> 2015-07-01 00:00:00 has changed since last month.
As others already mentioned, that's a problem of wanting to express
those timestamps in a timescale (UTC) that is already incompatible to
such "proper (predictive) representation" before a single computer ever
came into play.
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
More information about the questions