On Fri, Jun 26, 2020 at 2:27 AM Laurent Bercot wrote: > > > 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. > > Except it's not quite that simple either. As an example echo "s6" | s6-log -t /tmp/a && echo "djb" | multilog t /tmp/a && echo "s6" | s6-log -t /tmp/a Produces the following /tmp/a/current file on my system, roughly as a write this. @400000005ef64dd2075013a2 s6 @400000005ef64db707675514 djb @400000005ef64dd2077fa679 s6 There is a large problem there for someone building a tool to show timestamps that begin as TAI. Either the middle one is 27 seconds in the past or the first and last are 27 seconds in the future. If one wants to support djb tooling - then leap seconds are off the table - if one wishes to support s6 - leap seconds come on the table. What nosh supports is unknown to me. When lnav implemented the support - they did exactly what sounds reasonable - they took the tool they wished to support (multilog I would presume as it mentionds cr.yp.to) and implemented the code required to produce a view of that tool's logs. To say that is a lack of understanding is rather harsh here. John P.S. I totally appreciate s6 and all its beauty - I really just wanted to point out to the original poster that they need to double check because the worst thing one can do is miss something like this and then wonder why their logs are off when they go and look at a production system. 27 seconds seems obvious to catch - but in development one doesn't always focus enough - it's not like 2 hours or something more obvious.