4 ms·
Of course userspace may convert from what time() returns by spec to any given timezone. But it only does so if you instruct it like you did with TZ= or if it is
by IgorPartola 4y ago
Of course userspace may convert from what time() returns by spec to any given timezone. But it only does so if you instruct it like you did with TZ= or if it is programmed to do so somehow. I have not delved into systemd’s code but I can’t imagine it arbitrarily converts anything away from UTC time if /etc/localtime is set to UTC.
- viraptor 4y agoTZ doesn't do anything magic. It just tells libc you want your local timezone to be something different than the default. It affects output formatting in a way that the app mostly doesn't need to deal with if it only works with one timezone. I'm not even sure what claim you're making now, but the original msg is just wrong. If an app uses libc, it uses TZ setting - regardless if it's systemd or date or something else. > but I can’t imagine it arbitrarily converts anything away from UTC time if /etc/localtime is set to UTC. It really depends on which part of systemd you mean. There's lots of code in there and quite a few bits deal with timezones explicitly. (Since it sets it for users to begin with) But for basic display it sure uses TZ and localtime as set by the user - and it can be different than the system default. https://github.com/systemd/systemd/blob/cccc14c5a88f000931c67eaf3d776825aa2607f7/src/shared/logs-show.c#L417 https://github.com/systemd/systemd/blob/cccc14c5a88f000931c6...
- IgorPartola 4y agoYou and I are saying the same thing in different ways, except the part about systemd. I didn’t realize it did anything with timezones because I keep thinking of it as just modern initd but I guess it goes beyond that. I didn’t realize that if you remove all mention of local timezones from /etc/ that a user could still break systemd by setting their own TZ.