time_t typedef should be unsigned 32-bit (to avoid year 2038 problem)

[minida28]

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: NodeMcu v1.0
• Core Version: latest git
• Development Env: Arduino IDE v1.8.5
• Operating System: Windows 10

Settings in IDE

Problem Description

I am developing an application that rely on accurate date and time.

In ESP8266 Arduino environment, it seems the time_t typedef is still using signed 32-bit. If I use standard c++ time function (gmtime(), strftime(), etc), the date & time will only valid up-to January 19, 2038 03:14:07 GMT.

To proof it, please run below sketch. Basically the sketch supply fake UNIX timestamp 1 second before year 2038 bug is happened.

If I run the sketch below on NodeMcu, the date & time only valid up-to January 19, 2038 03:14:07 GMT, because the time_t variable become negative beyond that time.

But if I run it on Arduino Pro Mini, the time_t does not become negative, but the problem is now the year become 2068 !

It seems the the "zero" time on Arduino environment starts at January 1, 2000.

I am not sure if this is an issues or not (I think it is, that's why I report it here), or is it ESP82266 Arduino core related or SDK related issues, but isn't it better if the the application we develop should be Y2038 bug proof?

MCVE Sketch

#include <time.h>                       // time() ctime()

////////////////////////////////////////////////////////

#define ONE_SECOND_BEFORE_Y2038_BUG     2147483646 // Tue Jan 19 2038 03:14:06 GMT

////////////////////////////////////////////////////////

#define PTM(w) \
  Serial.print(": " #w "="); \
  Serial.print(tm->tm_##w);

void printTm(const char* what, const tm* tm) {
  Serial.print(what);
  PTM(isdst); PTM(yday); PTM(wday);
  PTM(year);  PTM(mon);  PTM(mday);
  PTM(hour);  PTM(min);  PTM(sec);
}

time_t now;

bool stopFlag = false;

void setup() {

  Serial.begin(115200);

#if defined(ESP8266)
  Serial.println();
  Serial.println(ESP.getFullVersion());
  Serial.println();
#endif

  now = ONE_SECOND_BEFORE_Y2038_BUG;

  Serial.println("Setup completed");
  Serial.println();
}



void loop() {
  if (stopFlag)
  {
    return;
  }

  static time_t prev = 0;
  if (prev != millis() / 1000)
  {
    prev = millis() / 1000;

    now++;

    printTm("gmtime         ", gmtime(&now));
    Serial.println();
    // human readable format
    char buf[60];
    strftime(buf, sizeof(buf), "%a %b %d %Y %X GMT%z", gmtime(&now));
    Serial.print("human readable : ");
    Serial.println(buf);
    Serial.print("time_t         : ");
    Serial.println(now);
    Serial.print("time uint32_t  : ");
    Serial.println((uint32_t)now);
    Serial.println();

    if (now < 0)
    {
      stopFlag = true;
      Serial.println("------------------ stop, time_t is negative ------------------");
    }
  }
}

Debug Messages

Output if run on NodeMcu

SDK:2.2.1(cfd48f3)/Core:win-2.5.0-dev/lwIP:2.0.3(STABLE-2_0_3_RELEASE/glue:arduino-2.4.1-13-g163bb82)/BearSSL:94e9704

Setup completed

gmtime         : isdst=0: yday=18: wday=2: year=138: mon=0: mday=19: hour=3: min=14: sec=7
human readable : Tue Jan 19 2038 03:14:07 GMT+0000
time_t         : 2147483647
time uint32_t  : 2147483647

gmtime         : isdst=0: yday=346: wday=5: year=1: mon=11: mday=13: hour=20: min=45: sec=52
human readable : Fri Dec 13 1901 20:45:52 GMT+0000
time_t         : -2147483648
time uint32_t  : 2147483648

------------------ stop, time_t is negative ------------------

Output if run on Arduino Pro Mini

Setup completed

gmtime         : isdst=0: yday=18: wday=4: year=168: mon=0: mday=19: hour=3: min=14: sec=7
human readable : Thu Jan 19 2068 03:14:07 GMT+0000
time_t         : 2147483647
time uint32_t  : 2147483647

gmtime         : isdst=0: yday=18: wday=4: year=168: mon=0: mday=19: hour=3: min=14: sec=8
human readable : Thu Jan 19 2068 03:14:08 GMT+0000
time_t         : 2147483648
time uint32_t  : 2147483648

gmtime         : isdst=0: yday=18: wday=4: year=168: mon=0: mday=19: hour=3: min=14: sec=9
human readable : Thu Jan 19 2068 03:14:09 GMT+0000
time_t         : 2147483649
time uint32_t  : 2147483649

gmtime         : isdst=0: yday=18: wday=4: year=168: mon=0: mday=19: hour=3: min=14: sec=10
human readable : Thu Jan 19 2068 03:14:10 GMT+0000
time_t         : 2147483650
time uint32_t  : 2147483650
...

[devyte]

@earlephilhower I seem to remember you looking into the y2038 problem as part of the certificate signing thing. What do you think?

[earlephilhower]

The SSL cert solution was to ignore it. axTLS will work with certs with validity dates < 2038, BearSSL should work beyond that as it separately accounts for days and seconds.

That said, this is a problem with date handling that's going to happen in 20 years to a single-sourced SOC running an Arduino environment. I'd put this at the bottom of the pile of things to worry about, frankly. Patching time_t means patching newlib and all the associated goodies therein.

[earlephilhower]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=4de8754bac676fc7f29082ccf8281b1c73ce629e

Newlib late last year seems to have enabled 64b time. We'd need to rebuild everything and make sure the OS never uses time_t in any structures or any library calls we define, though.

[devyte]

Given the previous analysis, that the solution is basically covered by a newer gcc/newlib, which is on the roadmap, I'm closing.
Also, I'd argue that certs that last too long don't make sense security-wise.

[minida28]

Thank guys, fair enough and nice to know that it's on the road map; I wish I have the skills and knowledge to contribute further.

Just for the sake of curiosity, my project is a pray time reminder (Led Matrix based).
In my country, such products are usually installed in mosques, to remind the pray time. Similar commercial products are available, and they claim the date & time will still be valid up-to year 2100.

I don't know if the product I am developing now can last for the next 20 years, but if it is, then at least I can rest assured that date & time won't jump back to 1901 while the actual year is 2038 :)

I will rely on third party library at the moment.

Cheers,