[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