Rolls of toilet paper left: 6
We have less than eighteen years to fix this, eighteen years I say. If we don't, we'll wake up on Tuesday 19th January 2038 and have a really big problem on our hands.
Most software engineers will know what I'm talking about. Its the 32-but signed integer problem. The one that is used to store the date & time. There are many ways of storing the date and time. From an ISO perspective, in written form it is YYYY-MM-DD HH:MM:SS ±NNNN, eg: 2020-03-29 21:12:24 -0700 from a computer's perspective it's: 1585541635. Or at least a lot of time. All Unix based computers, which include macOS / iOS do this.
Unix based computers store the date & time as the number of seconds since 1/1/1970. The time is stored based around UTC (or as us Brits would like the world to still call it, GMT). This number is then converted for display. This explains why a file you created at 4pm in London, says it was created at 8am when you look at the file date while located in San Francisco - it's slightly more complex than that thanks to daylight savings - which we should do away with BTW.
The largest number that can be store in a 32-bit signed integer is 2,147,483,647 (AKA: 0x7FFFFFFF), this is the number of seconds between midnight on the first of January 1970 and 3:14 am on the 19th of January 2038 (UTC).
The fix is easy, store the date in an unsigned 32-bit integer and we'll be OK until 2106.
Apple's HFS file system stored dates as the number of seconds since 1904. As an unsigned 32-bit number it all falls apart in February 2040. This can't be fixed for HFS, thankfully Apple have APFS now which is good until 2554.
Windows on the other hand, assuming they don't switch to a Unix kernel and file system, are OK until 2099.
Meanwhile, we have 18 years to get everyone to fix their code and databases - you did use an unsigned int everywhere now didn't you? Otherwise, we'll wake up in the morning and it'll be 1970 all over again. You have been warned, please don't wait until 2037 to do this.