On Sat 22 Oct 2016 at 16:42:57 (+0100), Joe wrote: > 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?).
Ah, now I realise why I couldn't understand your first answer: we're discussing a different problem. You're talking about the static problem of getting linux and windows to interpret the RTC in a way that is compatible with each other. My question relates to the OP's situation with no networking/NTP, but where the static configuration problems have been solved (where you've not succeeded), but with the RTC running non-UTC. And my question relates to the dynamic situation on two Sunday mornings of the year. I can sum it up as: With multiple OSes booting at various times, which OS is going to change the RTC by an hour, and how is it to communicate that it has done so to all the other OSes present on the computer, in order to prevent each one thinking that it has to make that change because *it* has total responsibility for the RTC. The six bullet points were to make the scenario concrete. One OS has changed the RTC to the new Local Time. It didn't use NTP to lookup the time; it merely noted that the time change must have occurred since the last boot, say, a week ago. The computer is happy. Now we boot up a second OS which makes the same observation: "Hey, I need to update Local Time because everyone changed their clocks last weekend." Do you see the problem? I don't see how to avoid it if you don't run a computer with RTC on UTC. > 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. I was under the impression that the solution (from Darac) was to set HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal to 0 or 1 in the registry. Do you do that? > 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 have to admit that I don't know how linux treats the time changes when the RTC is on Local Time. Does it look at /etc/timezone and the calendar and make the adjustment automatically. > > > 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. Yes, I was trying to keep it simple by ignoring clock drift. You may notice that I was also avoiding discussion of another problem: how to treat the Spring hiatus and Autumn duplication of time (apologies to our southern hemisphericals). This was just to concentrate on the particular problem of who owns/controls/has responsibility for the RTC. Cheers, David.
