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

["cpt.arsemerica.yahoo.com via supervision" <supervision@list.skarnet.org>]

> Yes. You cannot set your system clock to TAI, unless you want wildly
> incorrect results from time() [...]
>
In my world time() returns the SI seconds since the start of 1970.
Since TAI and UTC were off for fractions of a second
from 1970 to the end of 1972 might be true,
but my applications dont care for that time so much...
So I think my results are correct...
Just some little system clock frequency jitter (10msec) and
the round trip time of my VDSL internet connection (<40msec).
But that has nothing to do with /usr/share/zoneinfo/...


>>As long as the software uses glibc's time functions to break down
>>
>Have you tried it?
>
Sure... See:
% TZ=UTC date -d "2017-01-01 - 1 second"
Sat Dec 31 23:59:60 UTC 2016
% TZ=UTC date -d "2017-01-01 - 1 second" +%s
1483228826
% TZ=Etc/TAI date -d@1483228825
Sun Jan  1 00:00:35 TAI 2017
% TZ=UTC date -d@1483228825
Sat Dec 31 23:59:59 UTC 2016
% TZ=Etc/TAI date -d@1483228826
Sun Jan  1 00:00:36 TAI 2017
% TZ=UTC date -d@1483228826
Sat Dec 31 23:59:60 UTC 2016
% TZ=Etc/TAI date -d@1483228827
Sun Jan  1 00:00:37 TAI 2017
% TZ=UTC date -d@1483228827
Sun Jan  1 00:00:00 UTC 2017

I should also say,
that i do not only use a special timezone info file
( http://www0.wgboome.org/zoneinfo-TAI.tar.xz ),
but also a special NTP client,
that adds those 10 seconds,
which i could not do with that TAI file.

> gmtime() *will not work*, because it assumes a UTC system clock.
>
Yes. And that is what it gets...
I sym-linked that /usr/share/zoneinfo-leaps to /usr/share/zoneinfo

> Programs making their own assumptions, and there are a lot of these,
>
Yes, Everything that uses GLib... Javascript and balsa for example...
I patched balsa for myself (GLib devs refused to fix it properly)...
Somewhen I will find a patch for GLib's borkened interpretation of the zoneinfo files... Somewhen... :)

>>What would be wrong about the "-tttt" (localtime time stamp) option?
> 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 my case u wound land at TAI timestamps... :)
That's why i am asking...
I dont like to build packages myself...

> By recommending s6-log, I gave you the solution that requires from you
> the least amount of work and the least amount of waiting.
>
OK... s6-log uses localtime, when started with -T...
But that means another 1MiB on my litte root partition... giggle

I think, i will write socklog&svlogd myself...
Maybe i can even use less than 2MiB of main memory...

Or i continue to use svlogd without options,
but then the kernel log lines have a timestamp relative to boot time...
*face palm*