Linux clock loses 10 minutes every week

Solution 1:

HyperV is the disease, NTPd is the cure.

Where to look or what i could use to monitor those date change?

You can query the NTPd daemon (via the ntpq client) to get the difference between local clock and the NTPd servers reference clock. But that implies actually running NTPd so you are not monitoring your changes alone, you're monitoring the combined effect of your running local clock and NTPd keeping it in sync.

I don't actually know if you can configure NTPd to run (and give you the above mentioned metrics) but not to actually adjust the system clock. A different, and less efficient, way would be to periodically (cron?) run ntpdate -q against a set of reference NTPd servers and monitor its output, which will give you the difference between your clock and the reference without actually touching the local clock. Output will be like this:

$ ntpdate -q $YOUR_TLD.pool.ntp.org
[... list of queried servers ...]
17 Jul 12:14:11 ntpdate[42868]: adjust time server 109.168.106.59 offset -0.002517 sec

You could filter the last number and graph it to get a nice view of how much and when your clock jumps around:

$ OFFSET=$( ntpdate -q $YOUR_TLD.pool.ntp.org | grep adjust | awk '{ print $10 }' )
$ echo $OFFSET
0.002970

Solution 2:

NTP is not an unnecessary component.

It's the only sane way to keep a system clock updated against an atomic time source.

You should install NTP, configure it to use your local pool time source, and everything will be fine.

Solution 3:

In my tests I discovered that Hyper-V virtual machine clocks are very unreliable and frequently have a clock drift exceeding 500ppm. This is enough to cause even ntpd to fail. I had to switch to using chrony in these VMs to provide reasonably accurate wall clocks; it defaults to 1000ppm for this scenario and can be adjusted even further if necessary.

I no longer seriously consider Hyper-V for any application where timekeeping is especially important.