Range of year is very restrictive

[pjdupreez]

Maybe I am missing something, or the reason behind it, probably because of Y2K of some such reason, so please enlighten me, or add a clear note to the documentation.

The range of the year is (2000 -- 2099). This seems a bit restrictive, especially when trying to do get the difference between 2 dates in 2 different centuries.

For example:
`
DateTime now = DateTime (2023, 7, 19);
DateTime then = DateTime (1980, 5, 25);

Serial.print("Now: ");
Serial.print(now.year(), DEC);
Serial.print('-');
Serial.print(now.month(), DEC);
Serial.print('-');
Serial.println(now.day(), DEC);

Serial.print("Then: ");
Serial.print(then.year(), DEC);
Serial.print('-');
Serial.print(then.month(), DEC);
Serial.print('-');
Serial.println(then.day(), DEC);

// Serial Output
// Now: 2023-7-19 <-- correct
// Then: 2188-5-25 <-- problem
`

Like I said, I probably missed the reason for this decision, if it is documented, so would like to know if there is a way around this limitation. Thanks

[edgar-bonet]

The range in indeed a bit restrictive. The main reason, I believe, is that this library is meant for interfacing RTC modules. As you would use such a module to get the current date and time, the representation of historical dates falls then out of the scope of the library. Also, it turns out that most RTCs represent the year as one byte in BCD format (binary coded decimal). The year field hosts two decimal digits, which restricts the representable range to one century.

The DateTime class does not use BCD internally, and could in principle be extended to cover a wider range. Please, see issue #146 for some considerations which lead to the current choice.

especially when trying to do get the difference between 2 dates in 2 different centuries

This should work:

// From 1980-05-25 to 2000-01-01.
const uint32_t seconds_from_then_to_2000 = 618624000;

DateTime now = rtc.now();
uint32_t seconds_from_then_to_now =
         seconds_from_then_to_2000 + now.secondstime();

Edit: If you don't mind assigning a negative value to an unsigned number (which some may find objectionable), the following should also work, thanks to the rules of modular arithmetic:

uint32_t then = -618624000;             // 1980-05-25
uint32_t now = rtc.now().secondstime();
uint32_t seconds_from_then_to_now = now - then;

[pjdupreez]

Thanks for the clarification. Does make sense if the purpose is only for interfacing with RTC, I suppose. Ended up going 'old school' and doing the calculation by using seperate ints for year, month day (for other centuries) and using current time from RTC as inputs. Very verbose, but couldnt be bothered to find a library to do to that for me 😅

…

On Sun, 16 Jul 2023, 11:35 Edgar Bonet, ***@***.***> wrote: The range in indeed a bit restrictive. The main reason, I believe, is that this library is meant for interfacing RTC modules. As you would use such a module to get the current date and time, the representation of historical dates falls then out of the scope of the library. Also, it turns out that most RTCs represent the year as one byte in BCD format (binary coded decimal). The year field hosts two decimal digits, which restricts the representable range to one century. The DateTime class does not use BCD internally, and could in principle be extended to cover a wider range. Please, see issue #146 <#146> for some considerations which lead to the current choice. especially when trying to do get the difference between 2 dates in 2 different centuries This should work: // From 1980-05-25 to 2000-01-01.const uint32_t seconds_from_then_to_2000 = 618624000; DateTime now = rtc.now();uint32_t seconds_from_then_to_now = seconds_from_then_to_2000 + now.secondstime(); — Reply to this email directly, view it on GitHub <#289 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH4NCAMVFPHBRYWCNDIN33XQOYVDANCNFSM6AAAAAA2LYK7GU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Chris-70]

@pjdupreez you should probably close this.
Just to clarify the apparent DateTime design:

• Each value (Year, Month, Day, Hour, Minute, Second) is stored in its own byte, for a total of 6 bytes.
• The year is stored as an offset from the year 2000.
• The DS3231 and DS1307 chips also store the date and time in 6 different registers, plus another for the day of the week (1-7). The values are all stored in BCD format.
• This approach aligns well for reading/writing the date and time from/to the DS RTCs as just conversion from BCD to/from decimal decimal is needed, no calculations required for each field.
• The C# DateTime class (which appears to have inspired the RTC DateTime class) stores the number of ticks (100 nano-seconds) in a signed 64 bit (i.e. 8 byte) value since 0001-01-01 00:00:00. Every value must be calculated from this 64 bit value which adds some overhead.
• The RTC DateTime doesn't work when the DS3231 or DS1307 chips are using 12 hour mode (AM/PM). It also doesn't support:
  • The RTC day of the week, which is defined as 1 - 7 for the DS chips but never defines what 1 is. At initial power on, the time is: 2000-01-01 00:00:00 and the weekday is 1 (which is a Saturday, so Friday is 7).
  • The DS3231 century bit. Valid years are 2000 to 2199 for the chip. While the year offset is a value from 0 (2000) to 255 (2255), The century is bit is never read nor ever stored. This isn't an issue until 2100 but it is defined in the DS3231 chip family.

I addressed these issues and more in a fork of RTClib v2.1.4, that is a drop-in replacement, RTClibPlus as part of the WiFiBinaryClock project.