HN 提问：Azure Linux 虚拟机在重启后，如果 RTC 设置为 UTC 12:xx，会丢失 12 小时？
1 分•作者: klaas-•大约 1 小时前
提问 HN：Azure Linux 虚拟机 RTC 在设置为 12:xx UTC 时重启后会丢失 12 小时？
我注意到一个问题，并且可以稳定复现，但我没有看到有人讨论过。
其他人也能复现吗？我在不同地点的多个虚拟机上都轻松复现了这个问题，RHEL/Ubuntu 的表现相同，所以我相当确定这是 Azure 的问题，但并非 100% 确定 :) 考虑到这种情况应该会发生在每天 12:00 到 13:00 UTC 之间的每一次启动，我很好奇为什么只有我注意到它 :) 它会影响 systemd 的启动时间，我就是在这里注意到的——它声称更新没有安装，因为升级是在未来（提前 12 小时）安装的，而系统时间比那更早。
我猜测 Azure 在后台做了一些魔法操作，因为他们的 Azure Hypervisor 运行在本地时间，而 Linux 客户机倾向于使用 UTC RTC。在“正常”的 HyperV 下，从第一次启动时开始，会为每个虚拟机保存一个与 hypervisor 本地时间偏移量，但 Azure 似乎自动化了这一点？并且在那个“计算”过程中，他们可能在 AM/PM 或 12 小时制上出现了混淆？
复现步骤，RHEL9，禁用 chrony 覆盖 RTC，将时间设置为 12:xx，重启，观察到 00:xx 的 RTC 时间。
```bash
$ 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
```
查看原文
Ask HN: Azure Linux VM's RTC loses 12 hours on reboot if set to 12:xx UTC?<p>I've noticed a problem, and it happens reproducibly, but I have not seen this being talked about anywhere.<p>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.<p>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?<p>Reproducer, RHEL9, disable chrony from overwriting RTC, set fake time to 12:xx, reboot, observe 00:xx rtc time<p>$ sed -i.bak '/^[[:space:]]<i>rtcsync[[:space:]]</i>$/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