|
|||||||
This is a discussion on System Time Tripwire within the RollBack Rx forums, part of the Disaster Recovery Programs category; This morning I noticed that my PC system time was an hour out, the little time display at the bottom ...
![]() |
|
|
LinkBack | Thread Tools | Display Modes |
|
|||
|
This morning I noticed that my PC system time was an hour out, the little time display at the bottom right of the desktop (Win7) was showing me 7am instead of 8am.
Then I remembered I have been playing with different system configurations (very slowly, over the long term). I have an "up and running" snapshot where I just get on with the day to day things and try not to worry, and a "development" snapshot where I am (supposedly) refining my installation to be the way I really want it without having to hurry. It doesn't get looked at very often! I had a rush of blood a couple of days ago and fired up the development snapshot for the first time in a while. I didn't notice the notification (slightly strange), but my guess is that it thought it was it's first boot since the daylight saving change and put my system clock back another hour. |
|
|||
|
I might be talking out of my back side here, but I think this highlights a problem with contention. I'm not saying there's anything that can or should be done about it, just something to be aware of.
If information is split and held partly by the hardware and partly by the software (in this case the operating system), then there are going to be pitfalls when swapping software around without it being fully aware of the environment (since some of the environment is residing in a different and non-communicating software "universe"). I don't know for sure but I strongly suspect that Windows is implementing daylight saving by altering the HARDWARE system clock, and then remembering that it has done so in SOFTWARE. Another instance is invoked (which is the whole point of RBRx) and we enter a different universe, the OS doesn't know that daylight saving has already been applied and does it again. The same problem would occur in other multi-boot schemes, even ones involving physically swapping hard drives. If Windows didn't alter the system clock, but just kept a note that there needed to be a correction applied if the current date falls within "summer", there wouldn't have been a problem. Alternatively, if there was a hardware flag to say if and whether daylight saving should or has been applied, that information would be preserved between the universes and there wouldn't be a problem. I wonder what Linux does. |
|
|||
|
I guess that this would be an argument in favour of keeping the RTC as UTC rather than local time then each OS can adjust from the same reference point based on location and any DST rules in effect whenever they run. That's fairly easy to say when you live in the UK though!
I was trying to imagine a scenario where RB could get into a confused state as a result of time changes but I'm guessing that the time, to RB, is probably just a means of labelling snapshots to help the user. So it shouldn't matter from a practical point of view if you take a snapshot just before a DST backwards change and then another just after it has happened. The labelling should be the only oddity. At least, I hope it is .Graham |
![]() |
| Thread Tools | |
| Display Modes | |
|
|