Is DateTime from RTClib giving garbage dates/times?

Question

The RTC is working fine, but I'm having trouble with the DateTime class. Based on the following test, it seems like its math is wrong.

#include <RTRlib.h>
void loop()
{
 auto ts = TimeSpan(0, 8, 0, 0); // 8 hours
 auto zero = DateTime(0, 0, 0, 0, 0, 0);
 auto alarm = zero + ts;
 Serial.println(String("Zero date: ")+zero.year()+" "+zero.month()+" "+zero.day()+" "+ zero.hour()+":"+zero.minute()+" "+zero.second());
 Serial.println(String("Alarm as timespan: ")+ts.days()+"d "+ ts.hours()+":"+ts.minutes()+" "+ts.seconds());
 Serial.println(String("Alarm date: ")+alarm.year()+" "+alarm.month()+" "+alarm.day()+" "+ alarm.hour()+":"+alarm.minute()+" "+alarm.second());
}

My output is (repeating):

Zero date: 2000 0 0 0:0 0
Alarm as timespan: 0d 8:0 0
Alarm date: 2043 4 30 1:31 44

Also, when creating DateTime(0), I would expect the hours, minutes, and seconds to be zero. That's not the case. What's up with this library, and how did it get to be so popular if it doesn't work?

• Gerben: What is the value of alarmTime?
• Gerben: DateTime(0) isn't really supported as the library only works on dates after 2000. DateTime(0) will set the date to 1970, which looking at the source code doesn't work. But almost nobody would care. As for your primary issue, I wouldn't know why it isn't doing what you expect.
• Gerben: Try using the year 2001, just to be sure.
• piojo: @Gerben My mistake, alarmTime is removed. Thanks for spotting that.And I find it strange that DateTime(0) isn't supported, since that is the default constructor!
• Edgar Bonet: Any DateTime class will have some limits on the range of dates supported. Unless the practical limits are less that the documented ones, that's not a bug. However, you are right in pointing out that the default constructor is not useful. I just opened an issue on this point.

Answer 1

You are experiencing the consequences of code that doesn't do sanity checking. The library allows for dates that do not make sense (in addition to giving us all a new reverse-Y2K bug of assuming only dates later than year 2000.

When you create DateTime(0, 0, 0, 0, 0, 0);, you are saying to use Month 0 and Day 0. Those have no meaning in date calculations, which always assume that the first month is 1 and the first day is 1.

The rest of the library's code assumes valid dates, so when you give it invalid dates, unexpected behavior is to be expected!

Of you only modify your zero assignment to DateTime(0, 1, 1, 0, 0, 0); you will see behavior that is more expected.

• piojo: Thank you, I suspected I was doing something stupid. But that doesn't explain why the other constructor returns dates when given a number of seconds (DateTime(0)). Whether it's seconds since 1970 or 2000 (it should be the former), it does not look like a usage error to use that API for any non-negative argument, yet it does not give a sane date for small numbers.
• Edgar Bonet: Note that an RTC is meant to track real time, and since year 2000 will never happen again, there is no "reverse-Y2K bug" in that library. Or rather, that's a closed (invalid) bug. It does have a Y2100 bug though, but that's a limitation of the RTC hardware.
• piojo: @EdgarBonet The comment above the class definition is, "Simple general-purpose date/time class". It's also not private and not part of a namespace. So no, it's not a real time date class. It's a general purpose date class, which happens to be buggy. Irrespective of the fact that adafruit doesn't want to fix it in their fork.