[LEAPSECS] [time-nuts] Leap Quirks

[Magnus Danielson]

Michael,

Michael Sokolov skrev:

> Hello all,

> 

> This discussion about the meaning of UNIX and POSIX time_t in terms of

> UTC/TAI/whatnot that has just moved here from the time-nuts list has

> pushed some of my religious hot buttons, so I feel the rhetorical

> imperative to state my position.


You should be aware that the discussion was a discussion of what POSIX 
time_t and related POSIX functions are and are not providing. This is 
not to imply that it is THE perfect solution or has anything to do with 
precission timekeeping or for that matter the existence or not of leap 
seconds in the UTC to come.


> But first a disclaimer: I absolutely do not care about POSIX because it

> is a standard which I refuse to bow down to.  I only care about UNIX,

> the operating system that predates POSIX by at least a decade and a half.

> I use Ancient UNIX systems which predate POSIX and will never-ever-ever

> convert, so everything I say about UNIX time_t specifically applies to

> non-POSIX, pre-POSIX and POSIX-defying UNIX systems, not to anything

> POSIX-compliant.  Examples of systems I'm talking about are UNIX

> Version 7 from 1979, UC Berkeley's 4.3BSD from 1986 and my own

> 4.3BSD-Quasijarus from which I send this E-mail in the present.


Good for you. That the UNIX time_t is different from the POSIX time_t is 
one of the things which became clear during this thread. Something to 
know. You basically agree with this. Great.


> All that talk about whether UNIX time_t is supposed to track UTC or TAI

> or whatever is totally wrong.  It has nothing to do with any kind of

> precision timekeeping whatsoever, nor even with time itself in the

> strict definition of that term.  Instead it is defined as a rotation

> angle of a wall clock.  One good way to define Classic UNIX time_t would

> be "the number of second marks by which the hands of a civil time clock

> in Phoenix, Arizona have rotated since they displayed 1969-12-31T17:00:00".

> (Or replace Phoenix, Arizona with any other civil jurisdiction that is

> free of DST and adjust the time zone offset accordingly.)

> 

> The point is, it has everything to do with clocks in the non-precision

> civil sense and nothing to do with time as seen by physicists and

> metrologists.  Once again, UNIX time_t measures the rotation of clock

> hands on some city tower in Phoenix, Arizona, *not* time.  If the hands

> of a wall clock turn too slow or too fast relative to precision time,

> time_t speeds up and slows down accordingly.  Angle, not time!


The background for digging deep and discover what POSIX time_t was 
actually to discuss the availability of UTC and related timezone shifted 
variants to achieve local time as in civil time. This is not to achieve 
precise time in a metrologists sense, but there may very well be 
requirements for traceability for certain applications which is causing 
some of us some grief. Thus, talking in TAI or UTC form becomes 
necessary even if we are not talking metrologist quality of accuracy and 
stability.


> And while we are at it, in my definition a clock has absolutely nothing

> to do with time.  A clock is a *civil* device (not a metrological one)

> that tells people when to get up, when to go to bed, when to expect

> meetings, phone calls, etc. and when to catch a bus to go to work or

> school.  It has *absolutely nothing* to do with time as defined by

> physicists.  (To be fair, it has nothing to do with Earth orientation

> either, but the latter is a convenient reference to set clocks to in

> the absence of a trusted higher civilisation.)


Fine. But when we need coordinated time in computers we need some way to 
achieve it and some common time scale to measure along and adjust to. It 
can then be argued on the merits of vairious time scales for this 
purpose. The UTC with leap seconds and POSIX UTC to time_t mapping 
happends to be an unfortunate combination especially as we have leap 
seconds occuring.

We need to do these things for many reasons. Just realizing that POSIX 
does not provide exactly what we want is a good thing.

What you run on your systems is your thing and its all fine and dandy. 
We others may not have the same set of choices. I hope you don't have a 
problem with that. We need to solve those problems and have working 
solutions.


> Of course those of you who choose to obey POSIX or whatever will probably

> define time_t in some different way that takes precision timekeeping

> into account and thus has some connection to time scales such as

> UTC/TAI/whatever, but please realize that there are still non-POSIX

> UNIX systems in the world and whenever you receive any kind of

> communication over any network protocol from a non-POSIX UNIX system

> under my control that contains a time_t value, that value will measure

> the rotation angle of a clock in Phoenix, AZ, *NOT* time of any kind.


Well, we don't have a problem with that as such, however, IETF have 
specified UTC in their RFCs, such as RFC 3339 and assumed in for 
instance RFC5260 (altought not applicable to this case) so you are 
expected to deliver something which is at least similar to UTC in the 
emails you send. Not by us, but by IETF. It is there since this since it 
is convenient to have a common infrastructure for both time and format 
of time in order to make automatic detections of all various kinds. RFC 
3339 is on the standard track and is listed as a Proposed Standards. If 
you object to it, feel free to bring that issue to the IETF. This is not 
related to POSIX and is not directly correlated to how you choose to set 
your time_t, but related to how the emails out of your system looks. 
Then again, as long as nobody get you caught with sending horrendously 
wrong timestamps and blocking your email traffic you are probably home 
free never the less.

As for obeying POSIX, some of us must deliver POSIX so it is not much of 
a personal choice or preference. There is also possibilities to do 
things outside the real of POSIX which may be more appropriate for 
correct representations of various timescales such as UTC. This may 
still be outside the needs of high precission users but well within the 
needs of many real systems and this is the reason for us to discuss it.

Cheers,
Magnus