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=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30325 invoked from network); 26 Jun 2020 09:27:51 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 26 Jun 2020 09:27:51 -0000 Received: (qmail 31195 invoked by uid 89); 26 Jun 2020 09:28:16 -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 31188 invoked from network); 26 Jun 2020 09:28:16 -0000 From: "Laurent Bercot" To: "John W Higgins" , Supervision Subject: Re: Following log directories Date: Fri, 26 Jun 2020 09:27:49 +0000 Message-Id: In-Reply-To: References: Reply-To: "Laurent Bercot" User-Agent: eM_Client/7.2.37929.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeluddgudeiucetufdoteggodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucggtffrrghtthgvrhhnpedvgfevffeuleegvdektdffteegvdeiieefkeetgfeuheffheelheejhfevueeijeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht >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