On 27 April 2015 at 21:36, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > 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. > Why doesn't Windows follow this strategy then (not changing RTC)? Why change RTC for daylight savings? Actually, Fedora (most OSes) update the RTC to deal with drift compared to the more accurate time available from NTP, not to twiddle daylight savings. Updating the BIOS time is not primarily for DST > Apple's boot camp package patches Windows to deal with this problem, FWIW. > Which sounds like Apple got fed up with it too. > >>; 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 > Worth noting the bug being discussed and reasons for closing https://bugzilla.redhat.com/show_bug.cgi?id=1201978 refer to /BIOS/ time and the fact it does not have time zones. > >> >> <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. Basically the Windows approach (keep shuffling the BIOS clock and use flags to remember whether you've done it or not) is broken, or at least inherently fragile. Multi-boot shows this up. > >> 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. > No OS in a dual boot situation is a 'guest'. Unlike a VM guest the OS running on hardware is expected to be responsible for that hardware. I use Fedora daily and Windows less than once a week. Which is the 'primary' OS? Apparently Windows, since it wants to mess with the RTC. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
