[newRPL] Filesystem related date/time issues

[matthiaspaul]

The FAT file system supports dates from 1980-01-01 to 2107-12-31 (although not all implementations support dates after the 2099-12-31).

As discussed above, the newRPL code currently maps Samsung RTC register values 00 to 99 to years 2000 to 2099.

Since we have 2016 already, RTC year values lower than 16 should not normally occur in conjunction with any newRPL version supporting SD cards. If we take into consideration the possibility to backport the newRPL code so it could be used also in HPGCC-based libraries with the default HP 49g+/50g firmware, we might want to support a few earlier RTC year values as well, but hardly before ca. 2008 when the FAT library for HPGCC was originally developed.

I would therefore like to suggest to expand the range of supported years by eight more years to the full range supported by the FAT filesystem simply by mapping RTC year values 00 to 07 to years 2100 to 2107, while continuing to map 08 to 99 to years 2008 to 2099 as before. This would not increase the code by more than a couple of bytes.

Of course, the RTC hardware would continue to associate year values 00 to 07 with 2000 to 2007 rather than 2100 to 2107 internally, so the calculation of the day-of-week would become incorrect starting 2100. Fortunately, newRPL does not make use of the hardware day-of-week, so this does not impose a problem at all. Would newRPL need the day-of-week in the future, it would have to implement a day-of-week algorithm in software, anyway, since the hardware does not support dates below 2000 whilst the FAT file system does (and date stamps with years 1980 to 1999 are not unlikely to occur on media, so they can't be ignored).
The RTC hardware would also miscalculate leap years. However, for the span 2100 to 2107 there is a single date, where the calculation would effectively differ: The RTC hardware would assume 2100 to be a leap year and therefore 2100-02-28 to be followed by 2100-02-29, while in reality 2100 is no leap year and the 2100-02-28 will be followed by the 2100-03-01. The other leap year in the range, 2104, would be handled correctly, even if the RTC hardware would assume this to be 2004 internally.

So, the only drawback expanding the supported year range up to 2107 would be that users would have to manually increase the date by one day on or after the 2100-03-01 ("2100-02-29") a single time, and only when using the physical 49g+/50g calculator. The problem would not exist in the emulator. (It would be even possible to add code to silently correct the date, but I don't know if it is worth to add perhaps 100 bytes of code to cope with an event occuring only once. A note in the manual might do as well.)

https://sourceforge.net/p/newrpl/sources..._50g/rtc.c

Code:


int rtc_getyear()
{
   // CHG 2016-09-12 MPL: Max out FAT FS year range to 2107.
   int year;

   year = __getRTCYear() + 2000; // 2000-based
   if (year <= 2007) // RTC values 00..07 mapped to 2100..2107 (max FAT FS year)
      year += 100;   // Caveat: HW treats 2100 as leap year, so user will have
                     // to advance RTC by one day on/after 2100-03-01 once.

   return year;
}

https://sourceforge.net/p/newrpl/sources...datetime.c
With the above range expansion in place, this comment should be changed to:

Code:


year -= 1980;        // FAT epoch is 1980. Map 2008..2107 to 28..127

Without that expansion applied, the comment still needs to be changed as follows:

Code:


year -= 1980;        // FAT epoch is 1980. Map 2000..2099 to 20..119

Another case that would need checking: Does the RTC roll over from year 99 to 00, or does it stay at 99? If it does not roll over, users would have to manually set the date on or after the 2100-01-01 as well.

Greetings,

Matthias