time

purists' chronometer

purchron is a Perl program that provides a real-time clock display. The display can indicate not only the estimated current time, in several forms, but also a bound on the inaccuracy of this estimate. It correctly handles leap seconds and timezone offset changes.

A change log is available.

experimental code regarding time scales

Here is a collection of Perl code (with English commentary) implementing an object-oriented approach to handling multiple time scales (for all kinds of "time"). This is experimental work, attempting to determine how time-handling libraries and purchron (above) should cope with the modern profusion of time scales. Comments very welcome.

timezone-relative day count for Mars

Author: Andrew Main (Zefram) <zefram@fysh.org>. Date: 2007-02-17. Abstract:

Terran calendarists have found a need for a timezone-relative version of astronomers' absolute day count systems, and have defined such systems. The same need exists in Martian timekeeping. An absolute day count for Mars exists in the form of the Mars Sol Date (MSD), but there appears to be no established convention for a timezone-relative day count for Mars. This memo therefore defines the Chronological Mars Solar Date (CMSD), with the equation CMSD = MSD + 500000 + Zoff, where Zoff is the timezone offset in fractional days. Related quantities are also defined.

Available as plain text.

why time is difficult

Presentation by Zefram at the London Perl Workshop. Date: 2011-11-12.

Video maintained by Presenting Perl.

programming perspective on time scales

Author: Andrew Main. Date: 2013-08-20. Number: AAS 13-518. Abstract:

Present software and wetware suffer from a failure to grasp the philosophical and practical implications of the existence and availability of multiple time scales. Rethinking from a thoroughly modern point of view, this paper outlines the kind of API by which software of the future can better handle present and future horological needs, addressing both specialised and mundane requirements. Concerning the future of UTC, the new analysis challenges the notion that there is a meaningful decision to be made on whether to abolish leap seconds. Some practical issues in programming around leap seconds are discussed. Some technical requirements are identified, and some ideas that have been mistaken for requirements are unmasked.

Available as PDF, DVI, LaTeX source.

see also