Summary of the DebConf 2038 BoF

Everything from NTP to FAT will have to be changed, in a non-backwards-compatible way, and in most cases will break ALL interaction with other systems (e.g. NTP servers, storage devices) when you do so.

The "solution" is obvious. Any number of ways to fix it. The problem is implementing the solution in a way that allows people to keep using their computers.

Case in point - You have old tape systems with historical data on them, filesystem-dated, etc. (research data, archives, mortgage information, etc. etc.etc. - the era where timestamps were not duplicated into the files because it just took up unnecessary space, and you used old filesystems because you didn't have room for 64-bit values). You "upgrade" the filesystem modules to something new that allows you to move to 64-bit. You read an old file, and have to convert that date (from 1970 -> 2038) into the modern format. How do you ensure that - post-2038 - you know whether that file was really made in 1970 or 2038? Sure, newly-created file will be post-2017. But old ones? Are you going to silently trash the date fields for your users? "But they shouldn't be using them?" They why have them? And is your system going to think it's not been backed up in 40 years?

Or do you stop everyone's NTP server working with the established standard? Or does any NTP device now have to be redesigned? Or are you going to try to negotiate a compatible protocol with very expensive GPS / atomic clocks / etc. timekeeping devices running things like stock-exchanges, that were designed years before any such negotiation / protocol exists? Is the user just going to be told "Sorry, bin it." and have to buy a new one? I'm sure the manufacturers would love it, the users not so much. In fact they might just push back and say "I'm not going to upgrade my OS then, until 2038, and get another 21 years of usage out of this ridiculously expensive box".

It's not a "technical" problem, it's a practical one.

It's literally a case of trying to get users to move from "something that will work for another 21 years" to "something that will mean you have to spend lots of money and effort now". Sure, common sense would dictate the answer, but try running that past your company accounts department. "We have to spend this money now". "Why?". "Because if we don't, in 21 years time we might have the exact same problem but be 21 years closer to a solution and all our competitors will be having to do the same at that point anyway".

It's not quite as simple as just extending the timestamp field. It's breaking lots of entirely unrelated protocols. Will SMB1/2/3 wire protocols have to be redesigned? NFS?
NTFS? Word documents (what date format do they save in? Is it going to think the linked Excel file hasn't been updated in 58 years and refuse to honour it? TLS certificates? DHCP leases? Kerberos tickets? 32-bit dates are EVERYWHERE, and it's not a case of "just fix it in the kernel and everything is fine", it's literally getting the entire software library to be compliant, compatible, and able to read all its historical data too, without trashing data or even metadata the user may be relying on.

And there are LOTS of hidden dates. Do you know if the date used for the last replication of a HyperV/VMWare/etc. VM is 32-bit or 64-bit? I'm not at all sure I do. Maybe my VMs will decide the replication is too old and just stop? Or maybe it will force a simultaneous, all-VM immediately replication that then can't complete because the tickover confuses it?

Y2K is going to look like a party in comparison, and that cost billions and was relatively well-known to even ordinary users. Y2K38 is literally everything that ever touches a data being broken or unknown until someone redesigns the file format, network protocol or interaction with hardware.