Re: [svlogd] / -ttt / why UTC?

["Laurent Bercot" <ska-supervision@skarnet.org>]

>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, seconds,
>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* 
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