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.) 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 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. Cheers, David.
