Re: [RFC v4 07/24] time: Deprecate struct timezone members

[Florian Weimer <fweimer at redhat dot com>]

* Rich Felker:

> On Sun, Aug 11, 2019 at 03:52:45PM +0200, Florian Weimer wrote:
>> * Alistair Francis:
>> 
>> > On Fri, Aug 9, 2019 at 6:20 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>> >>
>> >> Alistair Francis wrote:
>> >> > -    int tz_minuteswest;              /* Minutes west of GMT.  */
>> >> > -    int tz_dsttime;          /* Nonzero if DST is ever in effect.  */
>> >> > +    int tz_minuteswest_dep;          /* Minutes west of GMT.  */
>> >> > +    int tz_dsttime_dep;              /* Nonzero if DST is ever in effect.  */
>> >> These two members should be declared with __attribute_deprecated__. And once we
>> >> do that, do we still need to change their names? I don't recall any other
>> >> instance of such name-changing.
>> >
>> > The name changing is coming from a suggestion here [1]. I do find it a
>> > little aggressive though as I do see some build failures, specifically
>> > for systemd.
>> 
>> Good point.  systemd does this:
>> 
>>         tz.tz_minuteswest = -minutesdelta;
>>         tz.tz_dsttime = 0; /* DST_NONE */
>> 
>>         /*
>>          * If the RTC does not run in UTC but in local time, the very first
>>          * call to settimeofday() will set the kernel's timezone and will warp the
>>          * system clock, so that it runs in UTC instead of the local time we
>>          * have read from the RTC.
>>          */
>>         if (settimeofday(tv_null, &tz) < 0)
>>                 return negative_errno();
>> 
>> It seems to me that struct timezone is not actually deprecated on the
>> kernel side when used with settimeofday.  This would be something which
>> has to happen before we can change its definition.
>
> The only effect I'm aware of it ever having had on the kernel side was
> actively harmful: applying the offset to the timestamps of all files
> on fatfs mounts. This has all kinds of consistency problems with DST,
> timezone changes, etc. and is lossy/destructive of data. Back in 2005
> I recall writing a script to do a best-case repair on digital camera
> timestamps (correctly recorded on the fatfs in UTC) that Linux mangled
> via moving them to hdd under several different local timezones.

Fair enough.  I filed:

  <https://github.com/systemd/systemd/issues/13305>

Let's see what happens.

> systemd should not be doing this at all. If anyone wants this feature
> it should be a mount option tzoff=..., not a global that's secretly
> set to match your system tz.

It looks like time_offset already exists.

Thanks,
Florian