![]() ![]() Will that respect the UTC setting? From my limited testing (my home Hyper-V server is a pale comparison to what I used to have in the office), yes, it does appear that this works fine, which makes sense as the Hyper-V integration services frequently sync the time between host and guest and people would complain if that didn’t handle differences in time zones between host and guest. OK, so what about a virtual machine? In Hyper-V, the Hyper-V integration services will keep the time in sync between the host and the guest VM. That should confirm the device is now in UTC (assuming it was properly set for whatever time zone the OS was configured to use after the reboot after the registry key was set). On a Surface device, reboot and hold down the volume up button, then go to the “Date and Time” option. The next way would be to boot into the UEFI firmware settings for your device. You can force a sync to get it to change back easily enough. How do you verify that it did any good? The first way is to see if the time on the device changed – the registry change doesn’t immediately take effect, so you’ll see a shift in the time (unless your time zone matched UTC). Of course the Wikipedia article doesn’t say what that registry key is, but a quick Internet search (finding a bunch of articles related to dual-booting other OSes, since those other OSes assume UTC) points to this value:Īlright, let’s say you make that change in the registry and then reboot. That’s good news, for two reasons: (1) UEFI supports UTC in the real-time clock, and (2) Windows 10 does too, but it needs a registry entry to force that to happen. ![]() On machines using a PC-AT real-time clock, by default the hardware clock still has to be set to local time for compatibility with BIOS-based Windows, unless using recent versions and an entry in the Windows registry is set to indicate the use of UTC. Time services include support for time zone and daylight saving fields, which allow the hardware real-time clock to be set to local time or UTC. UEFI provides device-independent time services. ![]() When doing some reading on UEFI I noticed this quote: an MDM sync) may be delayed (time hasn’t yet arrived) or skipped (time is already past). Anything with a specific scheduled time (e.g. The problem is the chaos that can cause in the process. Then the time zone can get set back to Central European time and it’s again 12 pm. Eventually, the OS will do a time sync and the time will shift to 3 am, assuming that happens before the time zone is changed. If you install a new Windows 10 OS image, it will boot up and assume that the time is in Pacific time, so in effect the time jumps forward 9 hours. So let’s say you had an old OS that was installed and configured for Central European Time where the time was 12 pm (noon). The OS will assume that the real-time clock is in that time zone. I’ve written enough about the challenges of Windows devices and the real-time clock that you’ve probably heard this one before: Windows stores the time in the real-time clock in the local time zone, which causes problems if you install a new OS on the device and it boots up in a different default time zone (usually Pacific). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |