So if the snapshot was taken one month ago – the time and date will report that it is still one month ago.
Interestingly enough, at this point in time we will be reporting the correct (with some caveats) time in the systems RTC.
When we restore a virtual machines from a saved state or from a snapshot we put back together the memory and run state of the guest operating system to exactly match what it was when the saved state / snapshot was taken.
This includes the time calculated by the guest operating system.
In order to deal with time drift in a virtual machine – you need to have some process that regularly gets the real time from a trusted source and updates the time in a virtual machine.But unfortunately the guest operating system has no idea that anything significant has happened – so it does not know to go and check the RTC and instead continues with its own internally calculated time.To deal with this the Hyper-V time synchronization integration service detects whenever it has come back from a saved state or snapshot, and corrects the time.The reason for this is that “time zones” are a construct of the software that runs in a virtual machine – and is not communicated to the virtual hardware in any way.So – in short – when we start a virtual machine there is no way for us to know what time zone the guest operating system believes it is in. As I have mentioned above – all time synchronization that is done by the Hyper-V time synchronization integration service is time zone aware.This real-time clock is backed by a small battery (you have probably seen the battery yourself if you have ever pulled apart a computer).Unfortunately virtual machines do not have any “batteries”.Once inside the guest operating system – these time readings are then delivered to the Windows time keeping infrastructure in the form of an Windows time provider (you can read more about this here: These time samples are correctly adjusted for any time zone difference between the management operating system and the guest operating system.This is done without the use of the Hyper-V time synchronization integration servers (it happens long before the integration services have loaded).The downside of this approach is that this does not take into account any potential time zone differences between the management operating system and the guest operating system.