All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Florian Weimer <fweimer@redhat.com>,
	Theodore Ts'o <tytso@mit.edu>, "H. Peter Anvin" <hpa@zytor.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	GNU C Library <libc-alpha@sourceware.org>,
	Karel Zak <kzak@redhat.com>,
	Lennart Poettering <lennart@poettering.net>,
	OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Subject: Re: New kernel interface for sys_tz and timewarp?
Date: Tue, 13 Aug 2019 21:31:21 +0200	[thread overview]
Message-ID: <87tvakuak6.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <ecf2742a-6cab-cc00-16ab-589fad07b8db@cs.ucla.edu> (Paul Eggert's message of "Tue, 13 Aug 2019 10:49:03 -0700")

* Paul Eggert:

> Linus Torvalds wrote:
>> I assume/think that glibc uses (a) environment
>> variables and (b) a filesystem-set default (per-user file with a
>> system-wide default? I don't know what people do).

> glibc relies on the TZ environment variable, with a system-wide
> default specified in /etc/localtime or suchlike (there is no
> per-user default). glibc ignores the kernel's 'struct timezone'
> settings for of this, as 'struct timezone' is obsolete/vestigial and
> doesn't contain enough info to do proper conversions anyway.

I think the configuration value that settimeofday changes is not
actually a time zone, but an time offset used to interpret various
things, mostly in a dual-boot environment with Windows, apparently
(Like the default time offset for extracting timetamps from FAT
volumes.)

This data has to come from *somewhere*.  The TZ variable and
/etc/localtime cover something else entirely.

Maybe it is possible to replace these things with other mechanisms
which exist today.  For example, the mount program could read a
configuration file to determine the system default for the time_offset
mount option and apply the value automatically.  The real-time clock
offset could be maintained by whatever mechanism hwclock uses.

I think whatever we end up doing, we should maintain consistency after
a system upgrade after architectures.  It does not make sense to keep
using the settimeofday hack on amd64 indefinitely, and switch to a
different mechanism on RV32, so that the two ways of supplying the
offset are never reconciled across architectures.

  reply	other threads:[~2019-08-13 19:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-13  9:05 New kernel interface for sys_tz and timewarp? Arnd Bergmann
2019-08-13 17:10 ` John Stultz
2019-08-13 21:45   ` Alexandre Belloni
2019-08-13 17:30 ` Linus Torvalds
2019-08-13 17:49   ` Paul Eggert
2019-08-13 19:31     ` Florian Weimer [this message]
2019-08-13 20:04       ` Arnd Bergmann
2019-08-13 21:56   ` Alexandre Belloni
2019-08-14  0:06   ` Theodore Y. Ts'o
2019-08-14  8:31     ` Arnd Bergmann
2019-08-14  9:09       ` Lennart Poettering
2019-08-14  9:32         ` Alexandre Belloni
2019-08-14 12:15           ` Lennart Poettering
2019-08-19 11:09           ` Karel Zak
2019-08-19 13:43             ` Thomas Gleixner
2019-08-19 13:49               ` Thomas Gleixner
2019-08-20 18:45                 ` Alexandre Belloni
2019-08-20 18:47               ` Alexandre Belloni
2019-08-20 18:58             ` Alexandre Belloni
2019-08-27 16:27               ` Arnd Bergmann
2019-08-27 16:31                 ` Alexandre Belloni
2019-08-14 16:26     ` David Laight
2019-08-14 16:47       ` hpa
2019-08-15 13:22         ` Arnd Bergmann
2019-08-15 15:05           ` Theodore Y. Ts'o
2019-08-15 15:24             ` hpa

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=87tvakuak6.fsf@mid.deneb.enyo.de \
    --to=fw@deneb.enyo.de \
    --cc=alexandre.belloni@bootlin.com \
    --cc=alistair.francis@wdc.com \
    --cc=arnd@arndb.de \
    --cc=eggert@cs.ucla.edu \
    --cc=fweimer@redhat.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=hpa@zytor.com \
    --cc=john.stultz@linaro.org \
    --cc=kzak@redhat.com \
    --cc=lennart@poettering.net \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.