To resolve this issue, use one of these options:
server ntp-1.example.com iburst
Note: This sends a burst of NTP messages, grooming the data at a much faster pace to reduces the initial delay in setting the clock.
If you configure the guest to use NTP, such time difference is corrected automatically. For time differences of up to 128 milliseconds (stepthreshold) NTP corrects the difference in a continuous manner, slewing at 1 second intervals. Otherwise, it steps the clock forward to the consensus time, but only after it establishes that the clock has consistently lagged behind for over a period of 900 seconds (called the stepout threshold).
Although unlikely, if the offset happens to be greater than 1 second, VMware tools running in the guest steps the guest clock forward immediately upon resume, to match the underlying ESXi host's clock. This is known as a one-time time synchronization, performed every time a virtual machine is resumed from a checkpoint, and only if the guest clock lags behind by more than a threshold value that defaults to 1000 milliseconds. The synchronization assumes correctness of ESXi host's clock, which, as per VMware's Timekeeping best practices, should be synchronized using NTP.
These time correction mechanisms are sufficient for most guest applications. However, some applications (such as those distributed over a network) may be highly sensitive to sudden time differences, and the ntp clock discipline algorithms too slow to mitigate its effects. For instance, in its default configuration, NTP may take up to 200 seconds to slew-correct a 100 milliseconds time difference.