On Thu, Jul 06, 2017 at 10:54:50AM -0600, Chris Murphy wrote:
On Thu, Jul 6, 2017 at 7:17 AM, Zbigniew Jędrzejewski-Szmek
> I don't have an opinion when (and if) to ask about the timezone,
> but it seems that people are attributing all possible problems to
> the wrong timezone, when in fact it should have little effect.
> In particular it should not have an effect on timestamps, unless
> you try to configure the computer with RTC in local time, which
> systemd warns about and which is broken.
UEFI spec very clearly states that the rtc is set to "current local time".
UEFI spec was "inspired" by Microsoft, so they repeated the same
idiotic thing that windows insists on.
UEFI runtime service provides GetTime() which always includes TimeZone
value in minutes offset from UTC, and Daylight bitmask so it is
possible to unambiguously derive UTC for the purpose of setting system
Right. It's "possible", assuming that the daylight offset
changes (and it does, e.g. quite recently in Venezuela). Once the
setter of the clock and the reader of the clock use different definitions,
it stops being reversible. A lot of complication for little gain.
All the kernel code I'm finding is ancient, based on EFI spec
which predates UEFI. I have no idea if it's abstracting GetTime() and
SetTime() correctly. From linux/drivers/char/efirtc.c I see a
reference for /proc/driver/rtc but when I cat that, there is no
timezone information, and DST is binary rather than bitmask (UEFI spec
has three possible states for DST, I think). So at least /proc is
exporting incomplete information, and it might be true that it may not
SetTime() completely either. So it's possible hwclock and systemd
simply can't get the TimeZone information that's exported by UEFI
runtime services GetTime().
I have installed shell.efi and it reports something rather weird,
whether I boot Windows or Fedora, and the clock is definitely either
local time or UTC:
Fedora has set the clock (UTC time was in fact 16:00 at the time this
command was issued):
Windows has set the clock (local time was in fact 10:10 at the time
this command was issued):
So what does the value in parenthesis mean? I have no idea. Not sure
what list to discuss this on, it's rather off topic for this list now.
And I've also looked at grub code, as they have a date command but
while it returns the day of the week (that's funny really), it doesn't
return timezone or DST. But the code itself has a bunch of timezone
related stuff in it, so maybe there's some other command that can dump
raw UEFI GetTime() - I haven't asked on the grub list yet.
Anyway, there's enough evidence here to be suspicious we're (all of
Linux not just Fedora) not doing things correctly regarding time and
timezone handling on UEFI.
Right. That only confirms that storing the hardware time in UTC makes
a lot of sense.