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

[jimlux]

On 8/8/19 4:24 AM, Greg Troxel wrote:

> 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.

which is essentially a time scale that is TAI with a fixed offset of the 
TAI time corresponding to "tick zero".
> 
> 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 :-)

Indeed, and I shout/type/think bad things about them periodically, such 
as now.


> 
> 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.

Exactly.

> 
> 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.

Yep - and how hard is that? the conversions to local time are byzantine 
enough, varying from place to place and year to year.  In the US, the 
candy industry has a big effect on the transition times.


> 
> 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.
> 

discontinuities in a time scale are a pain. As you say, for human 
reading, where you just want to make sure you show up for dinner on 
time, nobody cares about the leap second, or fractional millisecond offsets.

For situations where milliseconds matter (High frequency trading, for 
instance), then time scale choice, and how it is implemented, is important.