On first boot following dup to 20260302, I found clock advanced 5 hours. My LAN includes hosts that don’t know anything about UTC, so most hosts’ clocks are running on local time. I would have thought that the switchover of TZ management would have an automatic conversion mechanism to avoid the nuisance of need to run timezonectl to fix it. Is this absence a bug?
Not sure, all my systems use UTC, have a local ntp server and always softlink /etc/localtime to the relevant /usr/share/zoneinfo/../.. file.
# ls -gGh /etc/localtime /etc/adjti*
-rw-r--r-- 1 18 Feb 5 2015 /etc/adjtime
lrwxrwxrwx 1 38 Mar 6 2026 /etc/localtime -> ../usr/share/zoneinfo/America/New_York
# ls -gGh /disks/sslo/etc/localtime
lrwxrwxrwx 1 36 Apr 25 2018 /disks/sslo/etc/localtime -> /usr/share/zoneinfo/America/New_York
# ls -gGh /disks/s1*/etc/localtime /disks/s4*/etc/localtime
lrwxrwxrwx 1 36 Jul 16 2016 /disks/s131/etc/localtime -> /usr/share/zoneinfo/America/New_York
lrwxrwxrwx 1 36 May 24 2018 /disks/s150/etc/localtime -> /usr/share/zoneinfo/America/New_York
lrwxrwxrwx 1 36 Oct 31 2017 /disks/s151/etc/localtime -> /usr/share/zoneinfo/America/New_York
lrwxrwxrwx 1 36 Jan 10 2017 /disks/s152/etc/localtime -> /usr/share/zoneinfo/America/New_York
lrwxrwxrwx 1 36 Apr 3 2021 /disks/s153/etc/localtime -> /usr/share/zoneinfo/America/New_York
lrwxrwxrwx 1 36 Apr 3 2021 /disks/s154/etc/localtime -> /usr/share/zoneinfo/America/New_York
lrwxrwxrwx 1 36 Mar 12 2023 /disks/s155/etc/localtime -> /usr/share/zoneinfo/America/New_York
lrwxrwxrwx 1 36 Mar 12 2023 /disks/s156/etc/localtime -> /usr/share/zoneinfo/America/New_York
lrwxrwxrwx 1 36 May 5 2019 /disks/s423/etc/localtime -> /usr/share/zoneinfo/America/New_York
The Slowroll installation was an “upgrade” from either the subject TW, or Leap, so must have had similar /etc/localtime and /etc/adjtime before yesterday’s dup updated localtime. The future date above occurred due to my 6 where 3 belonged typo in setting the date after changing the CMOS battery.