TAI zone?

[Robert Elz]

    Date:        Wed, 29 Jun 2011 21:01:27 -0400
    From:        Paul Koning <paul_koning at Dell.com>
    Message-ID:  <B30EB3C3-48E8-47C2-BAFB-0D8916E3A579 at dell.com>

  | Wow.  Are you sure of that?

Pretty sure, yes (no leg pulling involved).   You can google "posix time_t"
yourself if you like (there's plenty out there on this topic).

  | If true, that is incredibly stupid.

That all depends upon your point of view.

  | It clearly isn't part of the charter of any such standard to redefine
  | the metric system.

Which isn't what they did, they didn't attempt to redefine TAI or UTC
(or even GMT) - they just define what a posix time_t value contains,
which is clearly something that is within its charter.   Whether you
agree with the result or not, there's no doubt of that.

  | Also, even if it does pretend to define it that way, it isn't
  | implemented that way in the real world.

It certainly is, one way or another - that's exactly what we deal with here.
The "linux" "right" set of data isn't a linux thing at all (of course), it
came from here (the tz project), and was an early attempt to do things
correctly (that's "right" as opposed to the "wrong" we actually have,
not right vs left or something).

But while it was right (or correct) in some sense of the definition of time,
it wasn't right according to the values in a time_t, which are really difficult
to alter, as time_t values are stored in all kind of unchangeable places
using the original definition (which is really that there are 86400 exactly
every day).

We still keep it around, for people who really need TAI time (or
genuine UTC), that just happens to not be POSIX, so almost no-one
actually uses it.   The quote from the linux doc

> - The "right" version is based on the International Atomic Time (TAI),
>   and it includes the leap seconds. [...]

is/was supposed to just mean that you have a hardware clock that's
ticking TAI (and so doesn't get adjusted for leap seconds), and then
the "right" data makes the leap second adjustment so when the data
is converted to human form we get the expected (UTC) result that matches
the clock on the wall, and from the radio etc.

  | I have never seen a system that uses nonstandard seconds,

I bet you have, as it is what just about everyone uses in practice.

The implementation doesn't necessarily use stretchy seconds (though that's
what BSD based unix systems do - they use the adjusttime() sys call whenever
the system clock is different from the correct time_t value  (usually
determined using the NTP porotocol), which causes the internal tick rate to
alter just a little until things are back in alignment).   Other systems
just alter the time value occasionally.  (After all, no-one has perfect
hardware counters, they all drift, except those few of us (or of you I
should say) who have genuine atomic clocks.)  Everything else has seconds
that don't match TAI or UTC reality anyway, and so constantly need corrections,
one way or another.   The occasional leap second correction is typically
more minor than the correction needed due to hardware imperfections.

If you have ever seen a system (other than one of those very expensive atomic
clocks) that genuinely ticks fixed length seconds, then more power to you.
All the rest of us live with stretchy seconds, all the time, and we don't
really suffer for it.   And maybe that is UT1 we're using, I haven't looked
at its definition to know if POSIX time is really it or not.

  | and I certainly will not tolerate such a system in any place where
  | I have anything to do with its design.

Feel free to do what you like, but if you're ever exchanging time data
with anyone else, and you're doing it in some second-counting format,
posix time_t's are almost certainly what you're getting.

kre