On Mon, Apr 27, 2015 at 10:52 AM, Simon Farnsworth <simon@xxxxxxxxxxxx> wrote: > 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. The point is that systemd gets fussy when RTC is in local time even if it's a single boot system. I don't know what the full consequence of its complaint is, but it complains nevertheless (via timedatectl) basically saying it's unsupported. Windows 95 and NT are completely different lineages and never supported dual-boot. Maybe Windows 95 followed by 98, or Windows NT 3.5 followed by 4.0 would have; just as it's possible to dual boot Windows 7 followed by 8. > 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 If there's evidence of another system present, maybe don't change the RTC? Just use it as a guide absent an Internet connect, and with one chrony can set system time without changing the RTC which only causes problems. Apple's boot camp package patches Windows to deal with this problem, FWIW. >; I've not looked at UEFI to find > out whether UEFI solves this. It's solved there, I have no idea if this is honored by the kernel or systemd though. http://wiki.phoenix.com/wiki/index.php/EFI_TIME > > <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? Seeing as Microsoft doesn't support either one of those for something like 20 years now, I'd say neither but still possible to infer another OS is already present and to leave the RTC alone and just adapt to a local setting and time service rather than insisting on changing the clock. > 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. If it seems like a mono OS installation, then its reasonable for the OS to assume it can assume complete ownership of the RTC. But just like a VM doesn't assert control over the real hardware RTC, a guest OS in a dual boot situation shouldn't either. If that guest is intending to be friendly, it ought to adapt rather than enforce a whole new policy the primary OS can't deal with. -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
