Re: New kernel interface for sys_tz and timewarp?

[Linus Torvalds]

On Tue, Aug 13, 2019 at 2:06 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> * Should we allow setting the sys_tz on new architectures that use only
>   time64 interfaces at all, or should we try to get away from that anyway?

We should not do TZ on a kernel level at all. At least not a global
one. It makes no sense.

If the original TZ had been defined to have some sane model (perhaps
per session? Something like that), it would be worth doing. As it is,
a global TZ is just plain wrong. Per process would be sane (but
largely useless, I suspect).

> * Should the NTP timewarp setting ("int persistent_clock_is_local" and
>   its offset) be controllable separately from the timezone used in other
>   drivers?
>
> * If we want keep having a way to set the sys_tz, what interface
> should that use?

I suspect we need to have _some_ way to set the kernel TZ for legacy
reasons, but it should be deprecated and if we can make do without it
entirely on architectures where the legacy doesn't make sense, then
all the better.

I suspect the only actual _valid_ use in the kernel for a time zone
setting is likely for RTC clock setting, but even that isn't really
"global", as much as "per RTC".

That said, if glibc has some sane semantics for TZ, maybe the kernel
can help with that. But I assume/think that glibc uses (a) environment
variables and (b) a filesystem-set default (per-user file with a
system-wide default? I don't know what people do). I suspect the
kernel can't really do any better.

                Linus