We investigated this issue and confirmed to be a bug in the OS. This issue impacts systems that doesn't have a CMOS RTC (real time clock). On systems without a legacy CMOS RTC, the HAL exposes a virtual RTC abstraction based on the system performance counter which tells time during instances (such as early and late boot) when the kernel can’t provide reliable answers.
As part of resume from hibernate, system runs into a race condition where the virtual RTC doesn't get fixed up correctly based on the performance counter and as a result the time tracked by RTC ends up being a bit further in the future. The kernel periodically ensures that it’s view of time is in sync with the RTC, and if that happens at just the right time, the kernel could get this wrong time in the future and use it as the system time, which would persists until NTP fixes it.
We are looking into the fixing this issue. In order to expedite the roll out of this fix, it would be helpful if you can provide information about your system and how often you run into it.
Thanks,
Eliyas
Everyone needs to realize that NTP can't usually automatically correct the time because the race condition time falls outside the maximum phase correction settings in the registry. The only immediate fixes are to run the NTP utility with a manual update, cycling the service on and off, or editing the registry settings per my 4/13 post and it will eventually update.