From: Florian Weimer <fweimer@redhat.com>
To: Rich Felker <dalias@libc.org>
Cc: libc-alpha@sourceware.org
Subject: Re: [RFC v4 07/24] time: Deprecate struct timezone members
Date: Mon, 12 Aug 2019 08:22:00 -0000 [thread overview]
Message-ID: <8736i6x06w.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20190811172829.GN9017@brightrain.aerifal.cx> (Rich Felker's message of "Sun, 11 Aug 2019 13:28:29 -0400")
* 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
next prev parent reply other threads:[~2019-08-12 8:22 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-10 1:03 [RFC v4 00/24] RISC-V glibc port for the 32-bit Alistair Francis
2019-08-10 1:03 ` [RFC v4 17/24] RISC-V: Hard float support for the 32 bit Alistair Francis
2019-08-10 1:03 ` [RFC v4 07/24] time: Deprecate struct timezone members Alistair Francis
2019-08-10 1:20 ` Paul Eggert
2019-08-10 1:30 ` Alistair Francis
2019-08-11 13:52 ` Florian Weimer
2019-08-11 16:59 ` Alistair Francis
2019-08-11 17:28 ` Rich Felker
2019-08-12 8:22 ` Florian Weimer [this message]
2019-08-12 15:42 ` Zack Weinberg
2019-08-12 20:20 ` Joseph Myers
2019-08-12 21:08 ` Zack Weinberg
2019-08-12 21:26 ` Joseph Myers
2019-08-12 22:13 ` Alistair Francis
2019-08-12 23:16 ` Zack Weinberg
2019-08-13 0:53 ` Paul Eggert
2019-08-13 1:04 ` Zack Weinberg
2019-08-12 22:11 ` Alistair Francis
2019-08-10 1:03 ` [RFC v4 03/24] sysdeps/gettimeofday: Use clock_gettime64 if avaliable Alistair Francis
2019-08-12 17:27 ` Joseph Myers
2019-08-10 1:03 ` [RFC v4 06/24] sysdeps/timespec_get: " Alistair Francis
2019-08-12 19:46 ` Joseph Myers
2019-08-15 18:03 ` Alistair Francis
2019-08-15 19:46 ` Joseph Myers
2019-08-15 20:52 ` Alistair Francis
2019-08-15 20:59 ` Joseph Myers
2019-08-15 21:16 ` Alistair Francis
2019-08-15 21:19 ` Joseph Myers
2019-08-15 21:23 ` Alistair Francis
2019-08-15 21:28 ` Joseph Myers
2019-08-15 21:35 ` Alistair Francis
2019-08-10 1:03 ` [RFC v4 15/24] RISC-V: Add path of library directories for RV32 Alistair Francis
2019-08-10 1:03 ` [RFC v4 10/24] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Alistair Francis
2019-08-10 1:03 ` [RFC v4 08/24] sysdeps/stat: Copy the statx struct to stat instead of stat64 Alistair Francis
2019-08-12 20:01 ` Joseph Myers
2019-08-12 22:26 ` Alistair Francis
2019-08-12 23:02 ` Joseph Myers
2019-08-12 23:10 ` Alistair Francis
2019-08-12 23:31 ` Joseph Myers
2019-08-13 20:40 ` Alistair Francis
2019-08-10 1:03 ` [RFC v4 12/24] RISC-V: define __NR_* as __NR_*_time64/64 for 32-bit Alistair Francis
2019-08-10 1:03 ` [RFC v4 05/24] sysdeps/clock_gettime: Use clock_gettime64 if avaliable Alistair Francis
2019-08-12 19:46 ` Joseph Myers
2019-08-13 23:48 ` Alistair Francis
2019-08-14 16:37 ` Joseph Myers
2019-08-14 18:12 ` Alistair Francis
2019-08-10 1:03 ` [RFC v4 04/24] sysdeps/wait: Use waitid " Alistair Francis
2019-08-10 1:03 ` [RFC v4 13/24] RISC-V: Use 64-bit timespec in clock_gettime vdso calls Alistair Francis
2019-08-10 1:03 ` [RFC v4 02/24] sysdeps/nanosleep: Use clock_nanosleep_time64 if avaliable Alistair Francis
2019-08-12 17:22 ` Joseph Myers
2019-08-14 18:24 ` Alistair Francis
2019-08-14 20:15 ` Joseph Myers
2019-08-14 21:39 ` Stepan Golosunov
2019-08-10 1:03 ` [RFC v4 16/24] RISC-V: The ABI implementation for the 32-bit Alistair Francis
2019-08-10 1:03 ` [RFC v4 09/24] Documentation for the RISC-V 32-bit port Alistair Francis
2019-08-12 20:02 ` Joseph Myers
2019-08-10 1:03 ` [RFC v4 01/24] sunrpc/clnt_udp: Ensure total_deadline is initalised Alistair Francis
2019-08-10 1:04 ` [RFC v4 20/24] RISC-V: Fix llrint and llround missing exceptions on RV32 Alistair Francis
2019-08-10 1:04 ` [RFC v4 22/24] RISC-V: Use 64-bit vdso syscalls for RV32 Alistair Francis
2019-08-10 1:04 ` [RFC v4 24/24] timerfd_settime: Use 64-bit call if avaliable Alistair Francis
2019-08-10 1:28 ` Alistair Francis
2019-08-20 20:11 ` Maciej W. Rozycki
2019-08-12 20:09 ` Joseph Myers
2019-08-10 1:04 ` [RFC v4 21/24] Add RISC-V 32-bit target to build-many-glibcs.py Alistair Francis
2019-08-10 1:04 ` [RFC v4 14/24] RISC-V: Support dynamic loader for the 32-bit Alistair Francis
2019-08-10 1:04 ` [RFC v4 11/24] RISC-V: define __NR_futex as __NR_futex_time64 for 32-bit Alistair Francis
2019-08-10 1:04 ` [RFC v4 18/24] RISC-V: Add ABI lists Alistair Francis
2019-08-10 1:04 ` [RFC v4 19/24] RISC-V: Build Infastructure for the 32-bit Alistair Francis
2019-08-10 1:04 ` [RFC v4 23/24] WIP: syscall.list: Call 64-bit versions of syscalls Alistair Francis
2019-08-14 18:39 ` Alistair Francis
2019-08-14 18:57 ` Florian Weimer
2019-08-15 21:43 ` Alistair Francis
2019-08-19 11:30 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8736i6x06w.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=dalias@libc.org \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).