Linux – Time too quick in debian, 72 minutes pass in system date in one real world second

NetworkManager is a likely culprit. NetworkManager will overwrite /etc/resolv.conf, and could explain the behavior you are seeing. However, I think NetworkManager typically adds a warning to the file like # Managed by NetworkManager, do not edit.

From the GUI, you can configure NetworkManager to not overwrite /etc/resolve.conf .

NetworkManager is considered harmful on many systems (Servers, virtualization hosts) because it overwrites your manual settings without warning you, and it doesn't support advanced networking features. You might want to to just shut down the service and prevent it from starting at next reboot.

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