[time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?

Greg Troxel gdt at lexort.com
Thu Aug 8 11:24:30 UTC 2019


Ralph Aichinger <ausserirdischesindgesund at gmail.com> writes:

> Another newbie type question: When thinking about how computers
> represent time, TAI would probably be the more logical way to store
> and do calculations with time, only including leap seconds when
> formatting time for human consumption. Or am I wrong in this?

There are two questions buried there.  One is "would it have been a
better design decision to use TAI", and the other is "given the way the
world is, is it better for me to use TAI", to which I would reply
"probably" (but that's an academic question) and "probably not".

> There are certainly people keeping all their clock settings to UTC/GMT
> even when their local timezone is quite a bit off.

I don't follow this sentence at all.  UTC and local time are not "off";
they are just different representations of the same thing (off implies
an error).  I'll take that as colloquial language as someone might say
something like "EDT is 4 hours off from UTC.  The second part is that
all UNIX-like systems keep their system clocks in almost-UTC (see
below), and have since the beginning, or at least before UNIX escaped
from the lab.  I remember a UTC (perhaps mislabeled GMT) system clock on
Sixth Edition Unix in 1977.

The POSIX specification says that unix time (what gettimeofday returns,
the numbers that are stored in the filesystem for mod times) is a
strange version of UTC, where it's expressed in seconds since the epoch
as if there were no leap seconds.

https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16
https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html#tag_21_03_00_20

So you should be aware that keeping your system clock in TAI is fighting
city hall.  If only the first few nerds who wrote UNIX were time nuts,
things might have been different :-)

The usual reason to want to use TAI for the system clock is to avoid
leap seconds in the local timescale, to get "t2-t1 is elapsed time, plus
to rail against the original decision to use sort-of-UTC instead of
TAI.

As I understand it, using TAI requires the timezone mechanism to be
extended to handle leap seconds, basically converting TAI to UTC before
converting UTC to lcoal time.

It also requires things like ntpd/chrony to convert the wire-format
timestamps (which in NTP are similar to Unix timeval, but with a
different epoch) to from/TAI.

I have the impression the above two are worked out, by time nuts who
have gone before you.

There are also other uses of time, in wire protocols, and in databases,
and I suspect those would need special handling and that some of that
special handling is missing.  For times you don't mind being wrong by
30s, it may not matter - but most people don't notice leap seconds, and
the idea that a time nut who wants to use TAI to fix leap second
discontinuities is ok with blurring TAI and UTC in other places does not
compute.

Are you just wondering, or trying to build a data recorder for use
during leap seconds?





More information about the Time-nuts_lists.febo.com mailing list