New

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 '/^[[:space:]]*rtcsync[[:space:]]*$/s/^/#/' /etc/chrony.conf
  $ systemctl restart chronyd
  $ hwclock --get
  2026-11-02 08:36:01.994014+00:00
  $ hwclock --set --date "2026-11-02 12:01:31.995048+00:00"
  $ hwclock --get
  2026-11-02 12:01:34.992128+00:00
  $ cat /proc/driver/rtc
  rtc_time        : 12:01:41
  rtc_date        : 2026-11-02
  alrm_time       : 00:00:00
  alrm_date       : 2026-10-31
  alarm_IRQ       : no
  alrm_pending    : no
  update IRQ enabled      : no
  periodic IRQ enabled    : no
  periodic IRQ frequency  : 1024
  max user IRQ frequency  : 64
  24hr            : yes
  periodic_IRQ    : no
  update_IRQ      : no
  HPET_emulated   : no
  BCD             : yes
  DST_enable      : no
  periodic_freq   : 1024
  batt_status     : okay
  $ systemctl reboot
  [...]
  $ ssh root@server
  [...]
  $ hwclock --get
  2026-11-02 00:02:48.993944+00:00
  $ cat /proc/driver/rtc
  rtc_time        : 00:02:53
  rtc_date        : 2026-11-02
  alrm_time       : 00:00:00
  alrm_date       : 2026-11-03
  alarm_IRQ       : no
  alrm_pending    : no
  update IRQ enabled      : no
  periodic IRQ enabled    : no
  periodic IRQ frequency  : 1024
  max user IRQ frequency  : 64
  24hr            : yes
  periodic_IRQ    : no
  update_IRQ      : no
  HPET_emulated   : no
  BCD             : yes
  DST_enable      : no
  periodic_freq   : 1024
  batt_status     : okay

Ran into this while swapping external drives between Windows and Mac -- it seems the only reliable way to keep the benefits of NTFS (journaling) and allow writes from MacOS is to use third-party $ commercial drivers.

I am not knowledgeble about what makes a driver so I asked (Gemini) -- and I am told this involves a fairly complex low level OS hooks and bypassing OS protections etc with a lot of edge cases -- so today's frontier models are unlikely to produce a reliable driver implementation.

I was surprised to hear. If we believe the AI marketing shouldn't this be solved relatively easily?