>I meant nothing towards s6 - but daemontools does not deal with leap
>seconds (or at least it cetainly looks that way from my foolish viewpoint).
Indeed, the tai64nlocal program from daemontools assumes that the
system clock follows TAI-10, which is a smart choice, but unfortunately
not the one that has been made by POSIX - which mandates the system
clock to follow UTC.
Assuming TAI-10 was a reasonable choice in 1998 (when daemontools was
written) because POSIX was not as commonly followed a standard as it
became several years later.
In 2020, however, TAI-10 is a niche setting that can only be done by
systems where all components are aware of it. Most software today
assumes UTC, and cannot be blamed for it because it just follows the
standard; daemontools' tai64nlocal is now the odd one out and does
not display accurate time on POSIX-compliant systems.
In the case of the s6-tai64nlocal program, which is s6's version of
its venerable daemontools counterpart, this is configurable at skalibs
compilation time: the default assumption is UTC, but the
--enable-tai-clock configure option will tell skalibs that the system
clock follows TAI-10.
Please bear in mind that this only impacts the time *display*, i.e.
when you want to print the current time to users, typically in a
broken-down fashion. The whole point of using TAI in the first place
is that time computations are kept simple and exact, and do not need
leap second awareness or clock torture techniques such as leap smear
(only Google is evil enough to have invented that). TAI is still the
correct way to represent time internally, and difficulties such as
"need to look at a leap second table" only arise when you want to
convert it to something that humans traditionally use, such as UTC or
local time, in order to display it in a form that is suitable for
human consumption.
>It looks like lnav took the concept from daemontools and ran with it - far
>worse decisions have been made by a tool trying to accomodate users.
It is definitely not a critical bug, but it is a bug nonetheless, that
shows a lack of understanding of the historical context, the use cases
of TAI and UTC, and the relationship between the two. It would be worth
reporting it to lnav, so it can print accurate information.
--
Laurent
Received on Fri Jun 26 2020 - 09:27:49 UTC