Yes. You cannot set your system clock to TAI, unless you want wildly
incorrect results from time() and similar system calls. Setting it 10
seconds earlier than TAI is the best you can do; and that's what the
right/ timezones expect.
In my world time() returns the SI seconds since the start of 1970.
Since TAI and UTC were off for fractions of a second from 1970 to the
end of 1972 might be true, but my applications dont care for that time
so much...
M. Bercot's point, which you edited out, is that what xe means by
"TAI-10" is exactly that, because what you say here is untrue. TAI was
different from UTC by over 10 seconds, not by merely fractions of 1
second, and the "start of 1970" in one was not the "start of 1970" in
the other. People don't use TAI in Unices and Linux-based operating
systems. They use what is more accurately termed TAI-10; because there
aren't versions of the timezone support data files (supplied "out of the
box") that count SI seconds and use "start of 1970" TAI, only ones that
count SI seconds and use "start of 1970" UTC, i.e. "start of 1970" TAI-10.
* https://unix.stackexchange.com/a/327403/5132
And whereas on an operating system like OpenBSD one should expect both
"right" and "posix" timezones to be supported, and any inconsistencies
in applications to be corrected with patches in ports, on Linux-based
operating systems the hotch-potch nature of the various language runtime
libraries and application repositories does not given one nearly as much
confidence that it's all correct.
Well done for trying to push corrections back to the authors; but that
makes you in a better position than most to agree with M. Bercot that
the state of the applications and Linux-based operating systems as
supplied leaves a little to be desired for TAI-10 operation. But as M.
Bercot and I both say, the major single offender here is {x,}ntpd.
I think, i will write socklog&svlogd myself...
Personally, I just go with the Bernstein timestamps. Then I can convert
to whatever human-readable form that I like, without touching the raw
log files or having to worry about parsing log files with
locale-dependent formats in them; even reading the same log entries in
multiple different timezones and locales if I really want to.
