Ask HN: Azure Linux VM's RTC loses 12 hours on reboot if set to 12:xx UTC?

I've noticed a problem, and it happens reproducibly, but I have not seen this being talked about anywhere.Can anyone else reproduce that, I have reproduced it easily with several VMs in different locations, both RHEL/Ubuntu behave the same, so I am fairly sure this is on Azure side of tihngs, but not 100% sure :) Seeing as this should then happen with every boot between 12:00 and 13:00 UTC I am wondering why I would be the only one noticing it :) It messes with systemds boot time, that is where I noticed it -- it claimed updates had not been installed because the upgrades were installed in the future (12 hours ahead) and system time was earlier than that.I am guessing Azure is doing some magic in background because they run their Azure Hypervisors in localtime and Linux guests like to have UTC RTCs, under "normal" HyperV there is an offset from localtime of the hypervisor being saved per VM starting with 0 on first boot, but on Azure I guess they automated it? And somewhere in that "calculation" they have an am/pm or 12hour confusion?Reproducer, RHEL9, disable chrony from overwriting RTC, set fake time to 12:xx, reboot, observe 00:xx rtc time $ sed -i.bak…