I’m running Home assistant OS on a Raspberry Pi 3B+
I’m on:
Home Assistant OS 7.0
supervisor-2021.12.2
core-2021.12.1
When I reboot my system, the date time is set incorrectly in the OS.
Because the date is so different, apparently NTP doesn’t fix it.
And because the date/time is wrong, anything that access stuff through SSL doesn’t work. (HTTPS, MQTT over SSL)
Every time I reboot my system, I have to physically go to the device, login to the shell and use date -s to set the time.
What brings you to this conclusion?
RPI’s have no baterry-backed clock, so they use a “fake” clock based upon the last time the device was shut down, until an internet connection is made an NTP is used. That works for millions of people
The evidence all points to that conclusion. Do you have another idea?
I installed an update, and then rebooted the raspberry pi later that day. The clock change to Oct 12th (determined by running the date command in a shell). But the current date was Dec 17th. I could ping internet servers, but the date did not get fixed by ntpd. I rebooted again and the date got reset to November. Again I could ping internet servers but the date didn’t change.
Why won’t NTPD magically fix this situation for millions of people? The NTPD manual says it won’t unless you call npdate -b.
NTPD can adjust your clock in slow increments if it’s off, clock slewing. The idea behind that is that slow steps won’t cause issues with software timers, strange gaps in log files etc.
The maximum slew rate possible is limited to 500 parts-per-million (PPM) by the Unix kernel. As a result, the clock can take 2000s for each second the clock is outside the acceptable range.
According to the manual page ntpd won’t work if your clock is more then 1000 seconds off.
Since slewing the clock to adjust it by 1000 seconds will take at least 3 weeks and during that time all date/timestamps are still off, that doesn’t seem unreasonable.
The ntpdate command has a -b switch to simply adjust the time without slewing. This is useful in cases where the the local system clock deviates too much from the “correct” time.