Re: Initial setup redundancy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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
> <zbyszek@xxxxxxxxx> wrote:
> 
> > 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
> time.
Right. It's "possible", assuming that the daylight offset never
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 0.92
> 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):
> 
> Shell> time
> 16:00:38 (GMT-34:07)
> 
> Windows has set the clock (local time was in fact 10:10 at the time
> this command was issued):
> 
> Shell> time
> 10:10:20 (GMT-34:07)
> 
> 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.

Zbyszek
_______________________________________________
desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Users]     [Fedora KDE]     [Fedora Announce]     [Fedora Docs]     [Fedora Config]     [PAM]     [Red Hat Development]     [Red Hat 9]     [Gimp]     [Yosemite News]

  Powered by Linux