Joseph Gwinn ([email protected]) wrote: John,
I've read your paper "Avoid Using POSIX time_t for Telling Time" (2016-12-08), and have some general comments: 1. Despite the resemblance to UTC, POSIX time is by intent *not* UTC, so all the observations that actual days can differ from 86,400 seconds and so on are correct, but beside the point - there are no leap seconds in POSIX Time. The reason is that POSIX Time must work in isolated systems, ones having no access to leap second data. This issue comes up from time to time, and there are a number of archived email fights on the subject, laying out the whole issue. POSIX Time is its own timescale, the details of which flow from the objectives and requirements of POSIX operating systems. While the POSIX Time Epoch is defined in terms of UTC (originally GMT), the progression rule is an approximation of atomic time - it just marches along, counting out seconds without reference to astronomy. 2. The new and modern timescale that most resembles POSIX Time is TAI. TAI was traditionally a paper clock, but the rise of IEEE 1588 Precision Time Protocol (PTP) has caused TAI to be implemented in practical time generation and distribution systems. Specifically, one can now buy GPS receivers that can be configured to publish GPS System Time, UTC, and now TAI. This makes it simple and direct to use TAI where one would have used UTC. Keeping in step with civil time is then performed only at interfaces where UTC or local civil time is required, the core of the system (with millions of lines of code) being blissfully unaware of leap seconds. 3. Over my career building large radar systems, the typical setup is that the radar runs on GPS System Time distributed as if it were UTC. This is achieved by setting the GPS receiver to emit GPS System Time, and letting NTP think that this is UTC. Actually, NTP botches leap seconds - a negative leap would cause the last second to be re-run, and a positive leap causes a time wobble. The radar software does notice these deviations from uniformity. The bump that a leap second would cause is intolerable in most such systems, so leap seconds are banned from the core. The displays and interfaces to external systems do any necessary conversion to and from UTC or local civil time. 4. FYI, typical radar software internally uses an integer count of clock ticks since their Epoch, which varies. The use of integer counts allows mathematically exact time arithmetic to be done efficiently. In these systems, time is a form of data, and not the clock on the wall. Think tracking of things flying by. One system from decades ago counted milliseconds "since Christ died" (well, the start of the Gregorian Calendar) in a 48-bit integer. More recent systems count nanoseconds in a 64-bit integer. Monotonic Time in POSIX is modeled on these timescales. Joe John Sauter ([email protected]) responded: Thank you for your comments, Joe. I agree that POSIX defines its own time scale for time_t, but that is not how it is being used. Everyone sets their computer’s clock to UTC, no matter what the standard says, and no matter how many seconds have passed since 1970-01-01T00:00:00Z. I have long heard that a design goal of POSIX was that it be functional in an isolated system, but I am not sure what that really means. A totally isolated computer might as well be switched off, since nothing communicates with it. That isn’t a reasonable meaning for “isolated” in this context, so what, really, is an isolated computer? Perhaps it means a computer with a very limited set of sensors for input, and a very limited set of effectors for output. If that is the case, surely one of the sensors can be a GPS receiver so the computer can keep its clock accurate. If not, then perhaps the computer’s clock doesn’t need to be accurate, and therefore has no need to update its leap second table. However, if a computer is going to track the Sun across the sky, it will need access to astronomical data, because the position of the Sun in the sky cannot be predicted to within a second five years in the future. Realistically, an “isolated” computer needs whatever inputs are required for it to do its job, and that might include the time. The TAI time scale was synchronized to UTC when it was created in 1958, and has since not counted leap seconds. Similarly, the Navstar GPS system was synchronized to UTC in 1980 and has since not counted leap seconds, making GPS time a fixed offset from TAI. GPS receivers, like your radar systems, convert to UTC when displaying time. The Navstar GPS satellites are informed of an upcoming leap second, and pass that down to the receivers, so they can display UTC correctly. I suppose your radar systems do the same. Your description of a typical radar system in part 4 is even simpler: just a count of seconds since its Epoch, converted to UTC for display. I am not clear from your description how the transition is made from NTP distributing GPS time as though it were UTC, to an internal seconds counter. Were you describing different radar systems? You may not have seen this reference from an October posting in the leap seconds mailing list: http://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.023.pdf The NIST Disciplined Clock outputs one pulse per second with astonishing accuracy. I dare say it would be good enough to provide clock to a radar facility. The pulses are nameless, and hence do not suffer from leap seconds. John Sauter
signature.asc
Description: This is a digitally signed message part
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
