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

[Alistair Francis <alistair23 at gmail dot com>]

On Mon, Aug 12, 2019 at 2: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
>
> No, but it might mean that these two functions are exceptions to the
> general rule of functions for 32-bit time being thin wrappers round their
> 64-bit counterparts.  (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.)

This is what I was picturing as well, with the individual members
marked as deprecated.

Alistair

>
> --
> Joseph S. Myers
> joseph@codesourcery.com