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 28836 invoked from network); 6 Apr 2023 18:12:42 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 6 Apr 2023 18:12:42 -0000 Received: (qmail 9830 invoked by uid 89); 6 Apr 2023 18:13:08 -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 9823 invoked from network); 6 Apr 2023 18:13:07 -0000 From: "Laurent Bercot" To: "cpt.arsemerica@yahoo.com" , "supervision@list.skarnet.org" Subject: Re: [svlogd] / -ttt / why UTC? Date: Thu, 06 Apr 2023 18:12:42 +0000 Message-Id: In-Reply-To: <1799016718.299578.1680785234404@mail.yahoo.com> References: <1799590563.259018.1680775861585.ref@mail.yahoo.com> <1799590563.259018.1680775861585@mail.yahoo.com> <1799016718.299578.1680785234404@mail.yahoo.com> Reply-To: "Laurent Bercot" User-Agent: eM_Client/9.2.1628.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >I don't know exactly what u mean with "TAI-10". >I guess u are refering to those 10seconds 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. >here i disagree a little bit: >As long as the software uses glibc's time functions to break down >"seconds since the start of 1970* to year, month, mday, hours, minutes, se= conds, >the software does not need any patches... >Ur link is a little bit misleading or outdated in that point... Have you tried it? localtime() will work if your timezone is correctly set, yes. gmtime() *will not work*, because it assumes a UTC system clock. Programs making their own assumptions, and there are a lot of these, will not work. Don't think everyone uses the libc; new compiled language ecosystems such as for instance Go or Rust have their own time libraries, and can you be certain they don't assume UTC? "As long as the software pays strict attention to the standards and follows them to a T even for non-100%-cookie-cutter cases" is a very strong hypothesis to make, even when you perform minor changes. Changing the way the system clock counts time is NOT a minor change. >What would be wrong about the "-tttt" (localtime time stamp) option? >Then I would not have to build/write my own *log daemon... >And svlogd just needs to use localtime_r(3)... In theory, nothing, except that it's a bad idea to timestamp logs with local time (hello, we're in the 21st century, we manage computers worldwide, we want logs to be shareable and mergeable across timezones). In practice, you're asking a maintainer to perform work that *you*=20 need, and that very few other people need. That's generally considered bad form. The way to go about it would be to implement the functionality yourself, and submit a patch; that said, since the last time we saw svlogd's maintainer was four years ago in a flash, I probably wouldn't bother if I were you. By recommending s6-log, I gave you the solution that requires from you the least amount of work and the least amount of waiting. -- Laurent