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. Regards, J. Bern -- *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 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions