On Thu, Jul 6, 2017 at 12:48 PM, Zbigniew Jędrzejewski-Szmek
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(a)in.waw.pl> 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.
Conjecture. It was an Intel and end user inspired spec, and now it's a
multi-vendor spec. There had to be, and continues to be, consensus for
the current approach to remain valid. Users become confused when their
firmware settings show the clock time mismatching from the wall clock.
No spec can prevent users from doing this. So the rational decision
was to let them win that battle, and just unambiguously encode time so
UTC could be inferred.
> UEFI runtime service provides GetTime() which always includes
> 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 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.
Why would the setter and reader be using different definitions? It
isn't that complicated, it's a single page of text that reads
unambiguously to me.
The EFI_TIME_ADJUST_DAYLIGHT bit indicates if the time
is affected by daylight savings time or not. This value does not
indicate that the time has been adjusted for daylight savings time.
It indicates only that it should be adjusted when the EFI_TIME
enters daylight savings time.
If EFI_TIME_IN_DAYLIGHT is set, the time has been adjusted
for daylight savings time.
In a place that does not honor DST, I'd expect Daylight is 0 (ergo
both EFI_TIME_ADJUST_DAYLIGHT and EFI_TIME_IN_DAYLIGHT are 0). Arizona
like Venezuala does not use DST.
Right. That only confirms that storing the hardware time in UTC
a lot of sense.
Sounds to me like emotional attachment. But it's also provably wrong
because more users are harmed by enforcing this policy in the dual
boot case, than anyone is helped by it.
The spec provides unambiguous time communication, which is all any
rational engineer should require. And yet so far Linux has decided to
abandon the UEFI spec for ideological reasons, and allowed all of the
same problems from the BIOS era to persist when there's no good reason
for doing so.