ado wrote:

Your correspondent's two cents: in setting up the time handling in UNIX, T&R got it exactly right with respect to springing forward and falling back when DST goes in to and out of effect--keep the computer counting monotonically and leave it to the software to translate the monotonic count into a representation of local time. What's right at the level of an hour is also right at the level of a second--keep the computer counting at one count per second, and leave it to software to figure out what should be displayed when the user asks what time it is.

Markus replied:

I don't agree. There is the important difference that UTC is today very widely disseminated, whereas TAI is a curiosity only known to time geeks like us. Keeping a computer synched to something like TAI would only be practical in the real world if a leap-free timescale (e.g., the existing TAI or GPS time) were widely enough available, along with a regularly updated UTC-TAI offset table. Current time distribution services, however, provide only UTC in easily accessible form, therefore running machines in TAI would likely cause them to get the leap second offsets wrong due to out-of-date leap-second tables rather quickly. Their timestamps would quickly get an integer number of seconds wrong relative to the timestamps of machines with up-to-date leapsecond tables.

I disagree with your disagreement. I ran machines using ado 'right_only' mode and synchronized by NTP, and they sailed smoothly through leaps with no fudging. The NTP code was modified to ignore leap warnings, and to add a single call to time2posix(). If those machines still existed they would still be synchronized no matter whether their leapsecond tables were up- to-date or not (although they would hiccup over leaps they were unaware of). Part of the problem might be in what you refer to as "timestamps". An ado 'right_only' system certainly doesn't believe that its raw time_t is a form useful as an external representation. Bradley