Incorrect date/year with most recent board lib

[bartgrefte]

Platform

• Hardware: NodeMCU v3.2 ESP8266 (Ebay 252712258856)
• Core Version: 3.0.0
• Development Env: Arduino IDE 1.8.13
• Operating System: Windows 10

Settings in IDE

• Module: NodeMCU 1.0 (ESP-12E Module)
• Flash Mode: Not available in Tools menu
• Flash Size: 4MB
• lwip Variant: v2 Lower Memory
• Reset Method: Not available in Tools menu
• Flash Frequency: Not available in Tools menu
• CPU Frequency: 80Mhz
• Upload Using: Both OTA and serial
• Upload Speed: 115200

Problem Description

NTP sketch from https://randomnerdtutorials.com/esp8266-nodemcu-date-time-ntp-client-server-arduino/ , that worked fine before, suddenly gives incorrect date/year, example output before and after NTP timesync:

08:29:15
Epoch Time: 2085985755
Month day: 6
Week Day: Thursday
Month: 8
Month name: August
Year: -3135390
Current date: -3135390-8-6

19:19:31
Epoch Time: 1622834371
Month day: 2
Week Day: Friday
Month: 12
Month name: December
Year: -3135405
Current date: -3135405-12-2

The time after sync is correct, epoch too, day/month/year are not, in the case of the year it's very obvious something has gone wrong.

No errors were reported and I tracked down the cause to the ESP8266 3.0.0 board library. If I downgrade it, followed by a reflash of the sketch, the problem is gone and output looks as expected:

12:01:52
Epoch Time: 1622894512
Month day: 5
Week Day: Saturday
Month: 6
Month name: June
Year: 2021
Current date: 2021-6-5

[earlephilhower]

This is a bug in the custom NTP library that sketch uses, and not in the core. We use NTP to get the date in the BearSSL_Validation example (because we need to know the date to check for HTTPS cert validity).

....
11:24:59.059 -> Try again after setting NTP time (should pass)
11:24:59.059 -> Waiting for NTP time sync: .
11:24:59.556 -> Current time: Sat Jun 12 18:24:59 2021
11:24:59.556 -> Trying: api.github.com:443...Connected!

My guess is the library they're using does not properly handle time_t size and ends up breaking. This release uses a 64-bit time_t vs the old 32-bit time_t (which has the year 2038 problem) as documented in the release notes.

I suggest contacting the NTP library author and letting him know about the 64b time_t. We're not alone in using this size, most OSes have moved there too so that things don't break (i.e. some HTTPS certs have validity beyond 2038 already, but there's no way to represent that date using the older 32b space).