On Sat, 22 Oct 2016 09:57:05 -0500 David Wright <[email protected]> wrote:
> On Fri 21 Oct 2016 at 18:47:43 (+0100), Joe wrote: > > On Fri, 21 Oct 2016 09:58:42 -0500 > > David Wright <[email protected]> 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. >
