On Wednesday 15 January 2020 14:50:10 Arnd Bergmann wrote: > On Wed, Jan 15, 2020 at 2:38 PM Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > > On Wednesday 15 January 2020 22:30:59 Namjae Jeon wrote: > > > 2020-01-15 19:10 GMT+09:00, Arnd Bergmann <arnd@xxxxxxxx>: > > > > It is not described in the specification. I don't know exactly what > > > the problem is because sys_tz.tz_minuteswest seems to work fine to me. > > > It can be random garbage value ? > > > > > > > so if there is a choice, falling back to UTC would > > > > be nicer. > > > > > > Okay. > > > > Arnd, what is the default value of sys_tz.tz_minuteswest? What is the > > benefit of not using it? > > > > I though that timezone mount option is just an old hack when userspace > > does not correctly set kernel's timezone and that this timezone mount > > option should be in most cases avoided. > > The main problem is that it is system-wide and initialized at boot > time through settimeofday() to a timezone picked by the system > administrator. > > However, in user space, every user may set their own timezone with > the 'TZ' variable, and the default timezone may be different inside of a > container based on the contents of /etc/timezone in its root directory. So kernel timezone is shared across all containers, right? > > So also another question, what is benefit of having fs specific timezone > > mount option? As it is fs specific it means that it would be used so > > much. > > You can use it to access removable media that were written in > a different timezone or a partition that is shared with another OS > running on the same machine but with different timezone settings. So... basically all userspace <--> kernel API which works with timestamp do not have information about timezone right? creat(), utime() or utimensat() just pass timestamp without timezone information. Is this timestamp mean to be in UTC or in local user time zone (as specified by user's TZ= env variable)? -- Pali Rohár pali.rohar@xxxxxxxxx
