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

[Zack Weinberg <zackw at panix dot com>]

On Mon, Aug 12, 2019 at 5:26 PM Joseph Myers <joseph@codesourcery.com> wrote:
> On Mon, 12 Aug 2019, Zack Weinberg wrote:
> > On Mon, Aug 12, 2019 at 4:20 PM Joseph Myers <joseph@codesourcery.com> wrote:
> > > On Mon, 12 Aug 2019, Zack Weinberg wrote:
> > >
> > > >  - Our implementation of gettimeofday should always pass NULL for
> > > > struct timezone to the kernel, and write zeroes to any struct timezone
> > > > argument that is supplied.  (This will transitively apply to ftime.)
> > >
> > > Given that the kernel timezone is in fact meaningful (for the kernel's
> > > interpretation of data shared with other OSes, such as the RTC clock and
> > > some filesystem timestamps, that is kept in local time - just not for the
> > > purpose for which the timezone settings in gettimeofday / settimeofday
> > > were originally intended), I think gettimeofday should continue to read
> > > that information from the kernel when the kernel provides it
> >
> > Insisting on this would mean that we'd have to go back to the kernel
> > people to request a new API _before_ we could proceed with the time64
>
>  (For the existing ABIs I think keeping interfacing
> with the kernel timezone is also a matter of ABI compatibility for these
> functions, even if the new _TIME_BITS=64 version of gettimeofday just
> writes zeroes to the timezone.)

I really can't agree with that.  At all.

The kernel time zone is a trip hazard for the overwhelming majority of
applications.  We would probably be _fixing bugs_ (well, rendering
them harmless) with the above proposed change to gettimeofday.

Also, I think having gettimeofday behave differently between different
architectures is a bad idea, and having gettimeofday behave
differently depending on _TIME_BITS is an even worse idea.  And we
know we _can't_ have gettimeofday mimic the old behavior when the only
available get-time syscall is clock_gettime, so...

zw