On Thu, Jul 6, 2017 at 12:48 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > 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. 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 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. 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 makes > 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. -- Chris Murphy _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
