-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NTPClient object sets time to 2036-02-07 #84
Comments
I have seen this problem as well. This date seems to correspond to an NTP time of 0x0000000 in the seconds component. Once the code subtracts 70 years, the resulting Unix time corresponds to the date above. |
I decided to to add some error checking, since then I haven't seen the problem. I've forked and committed my changes here: Summary:
|
Hi, I have the same problem. Maybe like this gmag11/NtpClient#70 last version Thanks! |
I am pretty sure that we are facing with rate limiting of NTP servers here. A simple check on the received response would do the trick: ignore the response if Peer Clock Stratum=0 and Reference ID='RATE' How to reproduce:
The default To trigger RATE limiting simply produce NTP requests exceeding the above limit. Related issues:
|
I kept getting this so set up a local NTP server but that hasnt made any difference. Are we any closer to getting a fix in place? |
Actually I found out that the DHCP server sends NTP server (option 42) address for IoT devices. In this case NTPclient behavior is the following:
My fix is the following:
With the above settings all my IoT devices relying on NTPclient are working stable. edit: i think that the original issue is that some sanity check of the NTP reply received is missing or insufficient. |
Could this please be fixed? |
I'm using the NTPClient in an arduino project.
Yesterday right after 19:40:53 CET the clock jumped to 2036-02-07 07:28:16. The object continued from this date on for about 2 more minutes until 2036-02-07 07:29:38 then it came back again to current time: 2019-12-04 19:42:18.
Does anyone know what might be the issue?
Based on this thread, which is quite related to this problem but with a different library, seems to be an internet connectivity issue. However why does the clock go to the future?
I am wondering if there has been done a patch for NTPClient.h
Additional context
Additional reports
The text was updated successfully, but these errors were encountered: