The year is stored as a two-digit BCD value (0 - 99) in the DS3231 real-time clock chip. Additionally there is a century flag or bit in the month register. Beside the figure showing the timekeeping registers,

the only reference to the century bit in the manufacturer documentation is the following sentence.

The century bit (bit 7 of the month register) is toggled when the years register overflows from 99 to 00.

Maxim Integrated Products, Inc (2015) DS3231 Extremely Accurate I 2 C-Integrated RTC/TCXO/Crystal, p. 12.

To me that means that the century bit does not identify a century. Looking at a lot of code on the Web, it seems some interpret it as follows (YEAR is the content of register 6).

  calendar year = (19 + Century)*100 + YEAR

Or if you prefer pseudo-code:

  if (Century == 1) then
    calendar year = 2000 + YEAR
  else
    calendar year = 1900 + YEAR

Which is reasonable, but why not let Century == 0 mean 2000 and Century == 1 mean 2100? That's more forward looking and it has a rather more pleasing symmetry. At least one library MD_DS3231 by Marco Colli (MajicDesigns) lets the user decide what the flag means. I cobbled together a Python script, called rtc, that can set or read the DS3231 time registers which implements the idea of dynamic centuries or a fixed century. The script runs in a virtual environment called rtcpy in which the smbus module was installed with pip. The Raspberry Pi on which the script is run has the latest version of Raspbian Buster which was updated and upgraded in February 2020.

After making sure that no I2C and RTC kernel modules are not loaded, the i2c1 module only is loaded. Thus as far as the system is concerned, there is no real time clock present, which means the Linux time synchronization daemon will not be trying to update the RTC.

The first command below sets the date to April 30, 2523. The century value is set to 2400 (-c 24) so the century bit will be set in the DS3231 registers. The century is not saved in the chip, so reading back the date without specifying a century, will not be correct as can be seen in the second command. The default century was used and it is 20 (for 2000). Since the century bit was set, the century was bumped up to 21 (for 2100), hence the year 2123. In the third command, the error is fixed by specifying the correct century -c 24. Of course if -c 25 had been set, then the date would have been off by 100 years as seen in the fourth command. In the last three command, the -f option is set which means that the century flag will be ignored. When only the -f option is given, the default century, 20 for 20000, is used. And, of course, the year is off by five centuries! The following command with the -f option and the century set to 24 will give the wrong year because the century flag is ignored while it was set to signal the rollover from 2499 to 2500. Only the last command is correct when the -f option is accompanied with the correct base century.

Let's verify that the RTC does use the century bit to indicate a rollover at midnight on the last day of the century.

Hopefully, this makes it clear how the DS3231 blissfully ignores centuries (except around midnight on the last day of xx99). There is something similar going on with the day of week register.

The day-of-week register increments at midnight. Values that correspond to the day of week are user-defined but must be sequential (i.e., if 1 equals Sunday, then 2 equals Monday, and so on).

Maxim Integrated Products, Inc (2015) DS3231 Extremely Accurate I 2 C-Integrated RTC/TCXO/Crystal, p. 12.

By changing the data of the DS3232 in a Linux system it became clear that the latter uses the range suggested in the documentation: the day of the week number is in the range of 1 to 7 with Sunday equal to 1. Unfortunately, Python uses a different convention: range of 0 to 6 with Monday equal to 0.

Here is the script.

(Download the script here: rtc.py.)

What does Linux do? The operating system marches to its own beat, the system clock which can be read or set with date or timedatectl. The utility hwclock can be used to read or set the hardware clock, independently of system clock. It can also synchronize both clocks. To star experimenting, the i2c1 module was removed to be replace by the I2C and RTC modules. Then I updated the RTC to the current system time. Finally, I turned off NTP updates, otherwise the system will be changing both the system clock and the hardware clock as we are trying to play with the time.

Note that date sets the system time only, whereas timedatectl sets the system time and the hardware clock if possible.

Valid times are constrained in Linux by the mechanism used to store time. The system clock is a 32 bit integer which holds the number of seconds since the so-called epoch which is 1970-01-01 00:00:00 UTC. The integer will overflow at 03:14:07 on Tuesday, 19 January 2038 UTC (see https://en.wikipedia.org/wiki/Year_2038_problem.

Not surprisingly, similar results obtain with timedatectl.

Of course, the DS3231 does not really care about such limits.

But hwclock does.

That makes sense since the utility can be used to set the system time from the hardware clock and vice-versa.

There will not be a Y2038 problem for the DS3231. Indeed, it could theoretically provide accurate time for centuries until time keeping changes over to the "stardate" system. Linux, on the other hand, will have to do something unless 32 bit systems no longer exist in 2038.