On Thu, Jul 6, 2017 at 10:54 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > 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) In case someone curious steps into the steaming pile I've injected... 34h07m = 2407m = 0x07FF And in the UEFI spec: #define EFI_UNSPECIFIED_TIMEZONE 0x07FF INT16 TimeZone; // -1440 to 1440 or 2047 If the value is EFI_UNSPECIFIED_TIMEZONE, then the time is interpreted as a local time. OK so both Windows and Linux are setting the TimeZone value to local time, but only Windows is actually using local time. But neither one is actually setting the timezone offset. So there is in fact no information to use here. And then I found this mess from 5 years ago, and then I got lost possibly due to all the gmane.org issues. http://linux-efi.vger.kernel.narkive.com/gY1o6abi/patch-2-3-rtc-efi-add-timezone-to-rtc-time-that-will-used-by-rtc-efi#post19 The status back then soundss like some hardware came with buggy firmware, so the EFI GetTime () was unreliable. No surprise there. But nevertheless on new hardware and Windows 10, this TimeZone variable is rendered useless near as I can tell. So we're stuck. And funny enough macOS does what we do, sets TimeZone to local time, but then sets the time to UTC. Perfect! Everyone's got exactly what they had before UEFI. -- Chris Murphy _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
