Use of TimeLib.h with this library demonstrates strange month calculation from TimeLib functions

[Makuna]

There is a report that when using the library Time (https://github.com/PaulStoffregen/Time) that some strange interaction can cause that libraries month() to return erroneous value of 13.

given a date and time of 2025/2/28 4:00 that code below would return a month of 13.

    RtcDateTime tmp = Rtc.GetDateTime();
    Serial.print("year() - "); Serial.println(year(tmp));
    Serial.print("month()- "); Serial.println(month(tmp));

[Makuna]

I created a test sketch to ignore the RTC and just work with RtcDateTime and the library in question. I ran it on ESP32 and didn't see any issues.

#include <RtcDateTime.h>
#include <TimeLib.h>

#ifndef countof
#define countof(array) (sizeof(array)/sizeof(array[0]))
#endif

void printDateTime(const RtcDateTime& dt)
{
    char string[40];
 
    snprintf_P(string, 
            countof(string),
            PSTR("RTC %02u/%02u/%04u %02u:%02u:%02u"),
            dt.Month(),
            dt.Day(),
            dt.Year(),
            dt.Hour(),
            dt.Minute(),
            dt.Second() );
    Serial.println(string);

    uint32_t totalSeconds = dt.TotalSeconds();
    uint32_t unixTime = dt.Epoch32Time();

    Serial.println(totalSeconds);
    Serial.println(unixTime);

    snprintf_P(string, 
            countof(string),
            PSTR("UNX %02u/%02u/%04u %02u:%02u:%02u"),
            month(unixTime),
            day(unixTime),
            year(unixTime),
            hour(unixTime),
            minute(unixTime),
            second(unixTime) );
    Serial.println(string);
}

RtcDateTime test(2025, 2, 20, 16, 20, 0) ; // 2025 2/20 4:20pm

void setup() {
    Serial.begin(115200);
    while (!Serial); // wait for serial attach
    
    Serial.println();
    Serial.println("Starting Test...");
    Serial.flush();

    delay(5000);
}

void loop() {
    delay(1000);
    Serial.println();
    printDateTime(test);
    test += 60*60*24; // add a day
}

and the output around that date and time

RTC 02/27/2025 16:20:00
793988400
1740673200
UNX 02/27/2025 16:20:00

RTC 02/28/2025 16:20:00
794074800
1740759600
UNX 02/28/2025 16:20:00

RTC 03/01/2025 16:20:00
794161200
1740846000
UNX 03/01/2025 16:20:00

[Makuna]

Dug into the breakTime() routine to see why its calculating just the month and day of month wrong.
line 193 of Time.cpp monthLength = monthDays[month];, the first loop through with month = 0, the returned value is 2! The monthDays array is corrupted.
at line 181 I inserted the following to dump the monthDays

  for (month = 0; month < 12; month++)
  {
      Serial.print(monthDays[month]);
      Serial.print(" ");
  }
  Serial.println();

then right before if (time >= monthLength) { I added the following

  Serial.print(month);
  Serial.print(" ");
  Serial.print(time);
  Serial.print(" ");
  Serial.println(monthLength);

the output looks like the following every time it loops over for the next day (starting 50 of course is different)...

0 0 0 0 0 0 0 0 184 184 184 184 
0 50 0
1 50 28
2 22 0
3 22 0
4 22 0
5 22 0
6 22 0
7 22 0
8 22 184

so, the serial dump of monthDays doesn't even match just a few lines down (notice the 28 for the 2nd item in the list even though the serial dump shows 0).
I don't know what to say, the code must be generated incorrectly?

[Makuna]

So, I added a local monthDays to the breakTime and changed the code to use it

const uint8_t monthDaysLocal[] = { 31,28,31,30,31,30,31,31,30,31,30,31 }; // API starts months from 1, this array starts from 0

and this works correctly.

RTC 2/20/2025 4:20:0
793340400
1740025200
UNX 31 28 31 30 31 30 31 31 30 31 30 31 
0 50 31
1 19 28
2/20/2025 4:20:0

Now, if that same local monthDays is also static (which it really should be), then it fails again.

static const uint8_t monthDaysLocal[] = { 31,28,31,30,31,30,31,31,30,31,30,31 }; // API starts months from 1, this array starts from 0

[parallyze]

That's quite some strange behavior. This is starting to get outside territory familiar to me, but I think I can follow why that's wierd.

The thing I'm struggling to understand is how this is affected by the Arduino IDE / differences from 1.8.18 (above things happen) and 1.8.19, where this does not happen. According to the git it's a security-release and the merged commits aren't really something that makes me suspicious regarding this error. Both, 1.8.18 and 1.8.19, use gcc7.3.0 as far as I can tell.

You're not testing using the Arduino IDE, are you?

This whole error doesn't make much sense, maybe that's why I forgotten about it.

The good thing is: Nothing seems to point into a direction related to your library. Even if the include-order is crucial up to 1.18.18
you've clearly proven something inside timelib is not working as expected.

If I can test anything, please let me know and thanks for looking into this so far!

[Makuna]

I am using Arduino IDE. I have found in the past that flags that are passed to the compiler have changed and that cause unintentional effects and BUGs. AVR for some reason has these issues popup every few years and I don't know why. I suspect they are looking for optimizations since it's truly an 8 bit processor with tight memory, and they don't use a wide enough test suit to catch this stuff.

My investigation was to see if I could find a root cause and understand why my library can cause any effect on another as it could popup elsewhere. But my library is pretty straight forward and the only thing is a PROGMEM array (pretty standard AVR). The timelib does do some funky things to override standard time header. I wouldn't use timelib on an avrtiny as its not very memory friendly; but this wasn't an issue in my test.

But at this point, I believe it is a code generation issue that happened to affect timelib and I will let others pursue it more.