On Sat, 22 Oct 2016 09:57:05 -0500 David Wright <deb...@lionunicorn.co.uk> wrote:
> On Fri 21 Oct 2016 at 18:47:43 (+0100), Joe wrote: > > On Fri, 21 Oct 2016 09:58:42 -0500 > > David Wright <deb...@lionunicorn.co.uk> wrote: > > > > > > . Neither OS was running when Civil Time changed to/from DST, > > > . After the time changed, one OS has run, updating the Local Time > > > to match Civil Time, . Another OS is just being booted up. > > > > > > What Local Time will eventually be displayed by this system? > > > > > DST may well be the answer. > > (I can't see how that answers anything, as I hadn't specified which > way time changed, nor can I see why it would be an answer in either > case.) It is *a* reason for inter-OS time shifting, it may be applicable to your or other peoples' cases. > > My concern is that the second OS to boot might apply the time change > in exactly the same manner as the first one did and should have done. > So the system's Local Time would end up an hour fast (were this late > Spring) or slow (were this late Fall) after the second OS applied its > own time change. > > Or IOW what mechanism is there for one OS to find out whether another > OS has altered the RTC by an hour any time recently?¹ > > > If I boot Linux on my Win8 laptop in the > > summer, it knows the time perfectly well. If I now boot Win8, the > > clock is an hour ahead. It does use a network time source but it > > does not query the source on boot, or soon afterwards. Eventually > > it will do so, but on a fixed schedule, so not for days, and there > > seems to be no way to fix it. It's not just the first time after > > DST arrives, it's every time. > > But isn't that just a configuration problem which I assume is unusual > in that most people are not reporting that problem? What's more, you > don't say whether your RTC is running UTC or some other time. > > Ignoring drift, a RTC running UTC never changes, so the hardware > always knows the correct time. The Local Time displayed is just a > matter of sensible configuration. > > My question, posed above, is *only* of concern where the RTC is > running non-UTC, ie it gets fiddled with twice a year. At these two > times, the RTC could be subject to incorrect alterations by > erroneously configured OSes, or even multiple OSes perfectly > configured, but unaware of each other's actions. I'm making the point that it isn't just at the point of change of DST that this happens, but at any time when DST is active. Both OSes use network time updates routinely, not just when they think the clock is wrong (how could they tell otherwise?). The issue is that when I made the Linux installation, I told it that the hardware clock should be set to UTC (the default), whereas the Windows installation will always assume local time. The two OSes will always be an hour out during the DST period, and if you're not in the UTC time zone, there will be a further offset at all times. This has always been an issue when dual-booting, when you would normally tell Linux to consider the HW clock to use local time as a workaround. > > > I give it a kick manually, which of course involves entering an > > admin password... > > which is the necessity we're trying to avoid. > > ¹ There's another similar concern should you have more than one OS > thinking it's responsible for measuring and taking account of clock > drift. Whether this is going to concern people who are rebooting OSes > all the time is moot. > For most computers, a second or two of clock drift won't matter, if network time is being used to reset it every few days or once per boot. I found plenty of people with this problem, and a few solutions. None of them worked, of course, this is the Internet. The brute force and ignorance answer is a script to force a network time update on Windows soon after boot, as Linux does, but it happens to me so rarely that I haven't yet worked up the enthusiasm. There's apparently no Windows configuration flag to do this, or at least not in 8. The laptop runs Windows pretty much all the time, but I occasionally visit an establishment with free public wifi. I won't use Windows on a network like that, so I have a Debian installation on a USB hard drive which I boot from on those occasions, which resets my hardware clock to UTC. This *is* the behaviour I want when booting my netbook from this drive, which I do more often, so there's no configuration which will keep the laptop happy. -- Joe
