Clock Discrepancy after Migration to New Hardware [RESOLVED]

I have been running HAOS on a Raspberry Pi 3b, but I received my Yellow today, so I made a backup of my HA instance and restored it there.

I have some automations that have template conditions that compare a sensor and a state attribute using as_timestamp() and those automations began firing when they shouldn’t after the restore. The template section in developer tools confirms that those conditional templates are now returning different results than they should (and did prior to the migration). I also see the same unexpected output as several other people in several old threads, but this more recent one matches mine most closely.

To be clear, {{ now().tzinfo }} returns the expected time zone as a location, and the time zone displayed in general settings is also correct (but shown as a GMT offset and time zone name vs the time zone location name returned in the former output), but {{ now().astimezone().tzinfo }} incorrectly returns UTC. Based on some other threads, I suspect that the Yellow’s hardware clock may be on UTC while the RPi’s wasn’t, but I would expect HomeAssistant to deal with that appropriately if it knows as much (and if it should but apparently doesn’t, I’d be happy to submit a github issue once someone can point me at what I need to see to confirm it is a bug).

The clock is right, so I’m assuming that NTP isn working fine (NTP problems seem to be the case in several threads that did turn up), but I’m open to checking/adjusting that config if someone can point me at the current way to do so (I’m not seeing the community addon mentioned in this old thread, and the port mentioned there is closed, but I don’t have a memory stick handy and would rather tweak this configuration without removing my USB devices which currently fill all ports).

I am leery of adding a homeassistant: section to configuration.yaml since I only deployed last year and everything is supposed to be managed in the GUI (which I already pointed out shows the correct time zone in system settings, too). Additionally, the fact of the matter is that it was working before without that, which makes me think there should be some config somewhere else for this.

Currently, I can work around this by subtracting from one side of the template in the affected automations’ conditions, but I’m concerned that this will lead to additional issues that are more inconvenient if I don’t get it corrected.

Can someone help me figure this out?

So I got to thinking and started to think it could be related to NTP. The Yellow would have been configured via DHCP and gotten good NTP before I set a static IP, which may have disabled NTP. I also had issues during deployment. Regardless, I had edited the configuration.yaml incorrectly and thought I had reverted that edit before rebooting after switching back to DHCP with a new reservation (challenge was dealing with the fact that MAC address isn’t provided on device or packaging). Since it wouldn’t start after that, a factory reset was the easiest way to get back to functioning, and everything worked as expected when I restored the backup after the factory reset. Could have been NTP or some strangeness in the first deployment (had quite a bit of trouble getting it going and restored the first time, guessing because it had an older version of HAOS then [9.3 vs 9.5]).