From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28961 invoked from network); 26 Jun 2020 19:52:56 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 26 Jun 2020 19:52:56 -0000 Received: (qmail 5957 invoked by uid 89); 26 Jun 2020 19:53:20 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 5950 invoked from network); 26 Jun 2020 19:53:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LTXqfErlBOBEOKiBKk10Q7gR4Of3EZsRXUGzVfWQFK8=; b=hakPPQI1zP/x66zZwKbv5YUQzw7Cvib+YPkXYINPb8YVKJg9L/Sc59gb/6F3bliJEB 5HhzsVrkjaU2ZIqmAmAvnchKztQH8B04VzEs80sKAGS3Hp6Xh5ILWlf+SpFNjyuA2Dev sPF9ZKT4p+HO4sQKzRWxz8Mn3iWVjKkSYazBK+TqhL2B1/e5MzsyAH6gtlfHnjZHxm8G L1NOS79+feLfY3FKEB/ncA27OqVLgBd2l2kqQDoGaAZ+xDQdxC0uyk4vAT7SG//eJidH c0reUs+lgJRT1HkeGg/03WgWXBg9M9MtG/zndrzuNnIB6aviMQhoOQCSuR4D2qpXK61W 3eow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=LTXqfErlBOBEOKiBKk10Q7gR4Of3EZsRXUGzVfWQFK8=; b=Xn2Kea+UlV7nZVartyIJqy9LF2p20uc7VGvfkKNvOJkVZRQHMHe23LuCKmvmjQTnWm W13mPnOK1/l+IyUSe4IooYte6y3wwo1I0dzotRDpKCZHU7I1Ze6B44DkzjPtkX72KPDk pgS+ICCf9ua11xDbKmSHm/y+azvDjIHABVc6AmWGv7sOYw9mvnG9/AnLzFA+Jw/LrbkN 4UhXwS+eB/PGbgMOxSSyvwiAkN6hKgt8bcRPIEzL/4mEfmz4weuOgZ1LHvHaA4pSu2SG Ml88JZN9yYwsZi85ADO5mXB4ut5IG+TSdOLQDfcozD/Ex2IxSxD15/0IYsFYiGD0cz80 07/Q== X-Gm-Message-State: AOAM531cLyjGzf8Ac9m7CdTuhk2R4vGwRCstE1Jqhk7AvWJAZ9ULgoRV Td2914srz/XGj7yzLYGKLWDx4k3xTTxefNyUzXEi385c X-Google-Smtp-Source: ABdhPJy7/eKZgAG1KCusP+b0Y7WdWUiK3EvMQz44bkGyKcIElGZve3lc8NaXh+YgENDWMREByYC/ZxpnB34jnZnkHpQ= X-Received: by 2002:a4a:bc8c:: with SMTP id m12mr3903137oop.44.1593201170360; Fri, 26 Jun 2020 12:52:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John W Higgins Date: Fri, 26 Jun 2020 12:52:39 -0700 Message-ID: Subject: Re: Following log directories To: Supervision Content-Type: multipart/alternative; boundary="000000000000d0afae05a9020dca" --000000000000d0afae05a9020dca Content-Type: text/plain; charset="UTF-8" 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. --000000000000d0afae05a9020dca--