NTP rollover-safe design with ESP8266 (Curiosity) The Arduino NTP implementation is rather naive in some respects. It basically just grabs the time in seconds from the raw packet, and then converts it to Unix time via subtraction. How would it be possible to create an implementation that is safe from at least this next NTP rollover (due in 2036)? I'd rather not design something that might suddenly fail in strange ways in a decade or two when I have forgotten why it might do so (but it's not horribly important if it's not easily fixed).

If it can make it to 2100, I'd have larger problems (the RTC would crap itself), so just this rollover is fine.

The existing implementation (https://github.com/arduino-libraries/NTPClient/blob/master/NTPClient.cpp):


unsigned long highWord = word(this-&gt;_packetBuffer[40], this-&gt;_packetBuffer[41]);
unsigned long lowWord = word(this-&gt;_packetBuffer[42], this-&gt;_packetBuffer[43]);
// combine the four bytes (two words) into a long integer
// this is NTP time (seconds since Jan 1 1900):
unsigned long secsSince1900 = highWord &lt;&lt; 16 | lowWord;

this-&gt;_currentEpoc = secsSince1900 - SEVENZYYEARS;
This implementation is perfectly fine. The calculations are done with
unsigned numbers, so they are naturally rollover safe. The day NTP time
rolls over, secsSince1900 will become a very small number, and
subtracting SEVENZYYEARS from it will cause an extra roll over. Owing
to the rules of modular arithmetics, these two rollovers compensate and
you are guaranteed to get the correct result modulo
232&nbsp;s.

In the end, you get a Unix time as an unsigned 32-bit integer. Unix time
is traditionally signed, which makes the 32-bit representation roll over
in January&nbsp;2038. The authors of this library have instead chosen to
represent it as an unsigned number, which means it will roll over in
February&nbsp;2106.