Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

[Simon Farnsworth]

On Monday 27 April 2015 10:39:40 Chris Murphy wrote:
>  On Mon, Apr 27, 2015 at 6:54 AM, Zbigniew Jędrzejewski-Szmek
>  <zbyszek(a)in.waw.pl&gt; wrote:
>  > On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
>  >> Time in UTC is just as absurd and arbitrary as time in a local
>  >> timezone,
>  > No, it's not. This has been written about many times, but in short:
>  
>  None of what you wrote explains a.) Why RTC in local works fine on
>  Windows; b.) why two users in this thread, including the original
>  poster, had problems with a stable timezone set.
>  
Windows doesn't work fine with RTC in local time, unless you have one and
only one Windows install on the system. If you (say) dual-boot Windows 95
and Windows NT 4.0 (I've done this in a work environment), and boot back and
forth between them on a DST change flag day, then both OSes expect to change
the RTC to reflect current local time. You then have to pull the RTC time
back to reality manually, as it's now out by one hour.

IOW, Windows works with RTC in local time if (and only if) it's the one and
only OS on the system that writes to the RTC. Fedora also writes to the RTC,
and thus we have to somehow co-ordinate changes with Windows in such a way
that DST adjustments only get applied once; I've not looked at UEFI to find
out whether UEFI solves this.

<snip>
>  > We could try to build an infrastructure to store tz information,
> and
>  > rebuild initramfses, etc, or we can just rip of the bandaid. This is a
>  > game of whack-a-mole which accelerates are systems get more dynamic
>  > and mobile that we cannot really hope to win.
>  
>  Hindsight being 20/20, obviously around 13 years ago Linux (and
>  friends) should have agreed to not fight the RTC being in local time
>  on multiboot systems, in particular dual boot ones with Windows.
>  Windows figures out what timezone the RTC is in by reading the
>  registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
>  which a Linux OS service could also defer to by default rather than
>  the adversarial relationship that's been chosen.
>   
Which registry entry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation?
The one in my Windows 95 install, or the one in my Windows NT 4.0 install?

Come to that, how is Linux supposed to find and read the registry, given
that it may not be allowed by administrator policy to mount the filesystem
that contains the registry? In the worst case, you dual boot the way I did
at work, where the machine's disk is in a cold swap caddy, and you cannot
physically get at the disk.

--
Simon Farnsworth