This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v4 07/24] time: Deprecate struct timezone members
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
transition. I don't like that idea. Also, unlike settimeofday where
we know there is at least one real, intentional user, I am betting
that all or nearly all existing uses of gettimeofday with a non-NULL
timezone argument are actually bugs.
Instead, what if we add Linux-specific set_hw_timezone(const struct
timezone *) and get_hw_timezone(struct timezone *) (sys/timex.h seems
like an appropriate place for the prototypes) that will call
settimeofday/gettimeofday now, or whatever new interface the kernel
people invent to replace this function, in the future. We can then
proceed to make both gettimeofday and settimeofday behave-as-if they
always calls clock_[gs]ettime(CLOCK_REALTIME) under the hood, and this
issue is decoupled from the time64 transition.
zw