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 On Tue, 13 Dec 2016 10:50:53 -0500, John Sauter wrote: > Eric, > > I attach a set of time manipulation subroutines I have been working on. > You can extract the sources from the PDF file using okular. > > These subroutines manipulate time expressed as UTC coded in a tm > structure. They extract the current time and allow addition and > subtraction of years, months, days, hours, minutes and seconds. They > also handle local time and deal properly with leap seconds. Details > are in the PDF file. > > I am planning to update the software to include the latest research on > historical values of Delta T, but this version will work until I can > get to that. I would appreciate any feedback you might have. > > Since these subroutines handle leap seconds while expressing time using > UTC, you can use UTC rather than TAI as your time scale. > > You said you are capturing meta-data about the devices from which you > capture time. I feel that this is absolutely required, and I > congratulate you for doing this. > John Sauter ([email protected]) > -- > PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E > _______________________________________________ > LEAPSECS mailing list > [email protected] > https://pairlist6.pair.net/mailman/listinfo/leapsecs _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
