[engolling]

Hi Werk,

I'm still on the last build and not the new update debug output of epoch time is still running:

Code:

Timestamp: 1573932519 Timestamp: 1573932579 Timestamp: 1573932639 Timestamp: 1573932699 RTC current date: Oct 30 2018 RTC current time: 19:31:40 Sending NTP request to sync clock... NTP replied UTC time from NTP server: 18:31:41 RTC adjusted to local time: 19:31:41 RTC current date: Oct 30 2018 RTC current time: 19:31:40 Timestamp: 1540927960 Timestamp: 1540928020 Timestamp: 1540928080 Timestamp: 1540928140 Timestamp: 1540928200 Timestamp: 1540928260 Timestamp: 1540928320 Timestamp: 1540928380 Timestamp: 1540928440 Timestamp: 1540928500 Timestamp: 1540928560 Timestamp: 1540928620 Timestamp: 1540928680 Timestamp: 1540928740 Timestamp: 1540928800 Timestamp: 1540928860 Timestamp: 1540928920 Timestamp: 1573933779 Timestamp: 1573933839 Timestamp: 1573933899 Timestamp: 1573933959 Timestamp: 1573934019

So what did I lern until now… Epoch time gets corrected after the new NTP sync at minute 31 of an hour at this moment the RTC still has the right time and date.
Then the time again changes in the minute after Tuesday, 30-Oct-18 19:48:40 UTC in RFC 2822
Exactly one minute later after the last change. So I'm curious what happens in the next hour.

Regards,
engolling

[werk_ag]

More and more I think the problem resides on the SyncProvider function, which runs every 3600s (1 hour) which seems when your system time gets wrong.
I don't know why this issue isn't happening to me, anyway later when I will get home I will try again.

In the meanwhile, after your tests, try find this line of code:

Code:

 setSyncProvider(syncProvider_RTC);

and disable it. If the problem disappear, we will start to know where the culprit is.

[engolling]

Next round - correct time lost at Tuesday, 30-Oct-18 20:47:40 UTC in RFC 2822

Resynced correctly at minute 31 of this hour.

Just disabled the sycProvider line.

I will give feedback in a few minutes.

Regards,
engolling

[engolling]

Disabling the SyncProvider fixes the issue for me.

Found the problem:

Code:

 Serial.print("Timestamp: ");  Serial.println(now());  Serial.print("Timestamp RTC: ");  Serial.println(RTC.now().unixtime());

Gives back the following:


Timestamp: 1540939999

Timestamp RTC: 1573944799


So RTC.now().unixtime() is not working properly.

[werk_ag]

What a mystery...

That is what I'm testing right now, and it is working for me, this may explain why I can't reproduce the problem. However, why is it working for me?

Code:

RTC Time: 1540937345 RTC Time2: 1540937379 Local Time: 1540937379 RTC Time: 1540937423 RTC Time2: 1540937439 Local Time: 1540937439 RTC Time: 1540937483 RTC Time2: 1540937499 Local Time: 1540937499 RTC Time: 1540937544 RTC Time2: 1540937559 Local Time: 1540937559 RTC Time: 1540937603

RTC_Time is the timestamp returned by the SyncProvider function. I'm testing it with a 45 seconds interval so its value can't be equal to RTC_Time2. Done just for checking what is retuned by the function.

RTC_Time2 is the timestamp read from the RTC right after the NTP update.
Local Time is obviously the local timestamp after NTP update (testing at 1 minute intervals).

Code:

time_t RTC_time2 = RTC.now().unixtime();           Serial.print("RTC Time2: "); Serial.println(RTC_time2);           Serial.print("Local Time: "); Serial.println(local);

Out of curiosity, what IDE version are you using? I'm compiling with 1.8.4, but I can also try with 1.8.6

[engolling]

Hi Werk,

things are getting even more strange:

Code:

 Serial.print("Timestamp: ");  Serial.println(now());  Serial.print("Timestamp RTC Unix: ");  Serial.println(RTC.now().unixtime());  Serial.println(RTC.now().year());  Serial.println(RTC.now().month());  Serial.println(RTC.now().day());

gives:

WiFi connection is ON
Timestamp: 1540941636
Timestamp RTC Unix: 1573946436
2018
10
30


So .unixtime() is doing strange things for me...
This comes from the time library, right?

I'm compiling with IDE 1.8.5 at the moment.

[werk_ag]

Yeah... seems that unixtime may not be performing always the same way.

If I'm not wrong RTC.now().unixtime() comes from the RTCLib, not the Time library

[engolling]

Found it in RTClib.cpp

Code:

uint32_t DateTime::unixtime(void) const {  uint32_t t;  uint16_t days = date2days(yOff, m, d);  t = time2long(days, hh, mm, ss);  t += SECONDS_FROM_1970_TO_2000;  // seconds from 1970 to 2000  return t; }

with #define SECONDS_FROM_1970_TO_2000 946684800 in RTClib.h

and

static long time2long(uint16_t days, uint8_t h, uint8_t m, uint8_t s) {
return ((days * 24L + h) * 60 + m) * 60 + s;
}

[werk_ag]

Yes, maybe the problem resides in the conversion form NTP time to unixtime

Unix uses an epoch located at 1/1/1970-00:00h (UTC) and NTP uses 1/1/1900-00:00h. This leads to an offset equivalent to 70 years in seconds

[41south]

My IDE is the latest 1.8.7 if that helps any