Thank you so much for the response. I left it on overnight, and now it has corrected itself.
root@RUT955:~# date
Tue May 21 16:26:36 UTC 2024
root@RUT955:~# gpsctl -t
1716308812
root@RUT955:~# gpsctl -e
2024-05-21 16:26:58
In Octave:
>> datestr(datenum('1970-01-01 00:00:00')+1716308812/86400)
ans = 21-May-2024 16:26:52
So, yes.
As for reboot/restart, the problem was first seen on RUT9_R_00.07.06.06, then we upgraded to RUT9_R_00.07.06.11, and it persisted.
root@RUT955:/tmp/log# uptime
16:41:25 up 20:00, load average: 0.15, 0.22, 0.12
Looks like no additional reboots since we left it last night.
Deliberately re-powering it now to see how it comes up. Immediately after power cycle, we get ‘5/3/2024, 4:56:51 AM’, which is wrong (today is the 21st), then we go back to being a whole epoch off: 10/5/2004, 4:46:51 PM, (System is set to sync time to GPS every five seconds). Then some 60 seconds later, it advanced to 5/21/2024, 4:48:32 PM, which is correct.
But I have some questions. Is there a place I can look in logs for more detail, ie. the clock being set?
I like that the event logs are numerically indexed. For example I can see back to events in March. But when I look within that range, it looks like the events are sorted by time, despite the indices. Going to the oldest log entries, I see 2001-02-02 (long before the creation of this modem). This continues until 2001-02-08, 1271 contiguous messages, before the clock advances to 2001-06-07. This continues until 2001-06-21, 2133 more messages, until it jumps to 2001-09-07 for 13 msgs before jumping to 2004-10-04 like I described yesterday, at msg 3418 out of 7460. At that point there are 28 msgs spanning from 19:52:41 to 20:49:23. That was yesterday when I was trying to fix it.
So, am I to assume that this device has been affected with this problem since we bought it in 2020? (2001-02-02 + 1 epoch = 2020-09-18)