1970-01-01 in Log

[FredFreegroup]

The Problem

After reboot some times it`s detects time as 1970-01-01
Can you stop posting this to log?

2025-06-03T09:13:34+0300,main,0264.342,264.342,264.342,0.000000,0.000,no error,0.0,2.0,6.0,4.0,3.0,4.0,2.2
2025-06-03T09:18:34+0300,main,0264.342,264.342,264.342,0.000000,0.000,no error,0.0,2.0,6.0,4.0,3.0,4.0,2.2
1970-01-01T02:00:36+0200,main,1554.N0N,,264.3420,,0.000,Rate too high - Read: 1554.302 - Pre: 264.342 - Rate: 1289.960,1.3,5.4,4.8,4.6,-1.0,0.6,-1.0
2025-06-03T09:32:16+0300,main,0264.342,264.342,264.342,0.000000,0.000,no error,0.0,2.0,6.0,4.0,3.0,4.0,2.4
2025-06-03T09:37:16+0300,main,0264.342,264.342,264.342,0.000000,0.000,no error,0.0,2.1,6.0,4.0,3.0,4.0,2.3

Version

Release: v16.0.0 (Commit: f542d84)

Logfile

2025-06-03T09:13:34+0300,main,0264.342,264.342,264.342,0.000000,0.000,no error,0.0,2.0,6.0,4.0,3.0,4.0,2.2
2025-06-03T09:18:34+0300,main,0264.342,264.342,264.342,0.000000,0.000,no error,0.0,2.0,6.0,4.0,3.0,4.0,2.2
**1970-01-01**T02:00:36+0200,main,1554.N0N,,264.3420,,0.000,Rate too high - Read: 1554.302 - Pre: 264.342 - Rate: 1289.960,1.3,5.4,4.8,4.6,-1.0,0.6,-1.0
2025-06-03T09:32:16+0300,main,0264.342,264.342,264.342,0.000000,0.000,no error,0.0,2.0,6.0,4.0,3.0,4.0,2.4
2025-06-03T09:37:16+0300,main,0264.342,264.342,264.342,0.000000,0.000,no error,0.0,2.1,6.0,4.0,3.0,4.0,2.3
2025-06-03T09:42:16+0300,main,0264.342,264.342,264.342,0.000000,0.000,no error,0.0,2.0,6.0,4.0,3.0,4.0,2.3

Expected Behavior

---

Screenshots

No response

Additional Context

No response

[FredFreegroup]

this causes the construction of such a terrible graph

[whitedavidp]

Seems like a clear case of the ntp not working yet. I have found that sometimes the mqtt and json data lacks a timestamp or that the timestamp is like this. My first issue was to allow internet access to the camera module in my router - which I had turned off - so ntp could never resolve. But still, after reboots, it can take a while for the ntp to resolve. I am not at all sure why.

I am currently looking to see if I can run some form on ntp relay on my router so that the I can eliminate the internet access and perhaps speed up the ntp response to the camera.

[friedpa]

Just look if your Router supports NTP. As far as I know, all newest do, but maybe you must enable it in the Router configuration.

[FredFreegroup]

Just look if your Router supports NTP. As far as I know, all newest do, but maybe you must enable it in the Router configuration.

as you can see from the log later - the date is normal. that is, he gets the time. the problem is that he wrote the incorrect date to the log before getting the correct one

[caco3]

This is not a bug but the intended behavior!
As long as we do not have the right time, we use the unix timestamp starting at 0.
This is only an issue on a cold start. If you do a restart, the NTP time does not get lost.

[whitedavidp]

Thanks. But I have checked and pointing the ntp server at my router's IP produces nothing. It is an Asus and while the firmware is quite complete, it does lack offering ntp services to connecting devices. At one point I started to look into modifications to do this. But it got rather deep, rather quickly.

[whitedavidp]

In testing changes to the ntp server, I found that a simple reboot does not seem to force time to be updated via ntp (at least not every time). For example (with ntp configured to my router's IP - which does NOT provide ntp services) followed by reboot, I get:

0d00h00m03s] 2025-06-03T17:19:33 <INF> [SNTP] TimeServer: 192.168.1.1
[0d00h00m03s] 2025-06-03T17:19:33 <INF> [SNTP] Configuring NTP Client...
[0d00h00m03s] 2025-06-03T10:19:33 <INF> [SNTP] Time zone set to PST8PDT,M3.2.0,M11.1.0
[0d00h00m03s] 2025-06-03T10:19:33 <INF> [SNTP] time zone: -0700 Delta to UTC: 25200 seconds
[0d00h00m03s] 2025-06-03T10:19:33 <INF> [SNTP] Time is already set: 2025-06-03 10:19:33

In order to force ntp to run, I had to cut power and restore it.

[whitedavidp]

From here:

Jan. 1, 1970
Linux is following the tradition set by Unix of counting time in seconds since its official "birthday," -- called "epoch" in computing terms -- which is Jan. 1, 1970

So until the clock is updated by ntp, this will be the "current" date. Ultimately, when ntp succeeds, the date get "properly" set.

So in this condition, what should be reported until ntp succeeds? I have gotten empty timestamps in json and mqtt data. Not sure that is "better" than using the 1/1/1970 date.

Still I agree that getting this in-between what seems like reasonable dates in the log file shown is strange. Makes me wonder if the O.P. filtered the log shown.

[BugHunter2k]

I have this too, is it possible to remove this lines from the log to get the graph to a resonabnle scale again?

[whitedavidp]

Removing line from the log would have no impact. The problem is the clock time on the unit. Is it being set properly via NTP?

[BugHunter2k]

The clock is set properly, but not after a cold boot. My log looks the same a in the starting post:

2025-07-23T19:05:54+0200,main,0445.0767,,445.1651,,0.0000,Neg. Rate - Read:  - Raw: 0445.0767 - Pre: 445.1651 ,10.0,4.0,4.0,4.9,1.2,7.9,6.9,7.2
1970-01-01T01:00:35+0100,main,0445.1117,,445.16510,,0.0000,Neg. Rate - Read:  - Raw: 0445.1117 - Pre: 445.1651 ,10.0,4.0,4.0,5.0,1.1,1.1,1.7,7.4
2025-07-23T19:13:45+0200,main,0445.1127,445.1127,445.1127,0.002609,0.0010,no error,10.0,4.0,4.0,5.0,1.1,1.2,2.7,7.9
2025-07-23T19:16:45+0200,main,0445.1194,445.1194,445.1194,0.002233,0.0067,no error,10.0,4.0,4.0,5.0,1.1,2.0,9.3,4.0

The 1970 date is the time i had cut the power and it restarted.

I totaly understand that the time isn't right at that point, but may be it would be advisable to wait for a proper time-sync beforestarting the first round.
Or at least filter these values for the graph display, to have a proper x-scale. That's what braught me here

[whitedavidp]

I see. Good luck with that.