This is so well taken care of that it’s really [not] going to be news, and we’ll have forgotten when this is supposed to happen, but interesting tidbit still: “The Epochalypse”. This transition actually started already a couple of years ago, but I guess it’s now actually implemented (see Debian wiki page for this).
"As of 2025, this is less that 13 years away, and plenty of systems that will have problems have already been shipped"
"Debian is side-stepping the Y2K38 bug – also known as the Unix Epochalypse – by switching to 64-bit time for everything but the oldest of supported hardware, starting with the upcoming Debian 13 “Trixie” release."
[…] "The fix is to move to a 64-bit integer, even when running on 32-bit hardware. It’s no small change: Debian’s maintainers found the relevant variable, time_t, “all over the place,” spread across a total of 6,429 packages. As the move requires a breaking change to the application binary interface (ABI), it also has to happen across all affected libraries simultaneously."
Do it as many Windows 10 users do: don’t upgrade your system and the party can begin.
Or, if you are a nerd that has lots of fun with numbers → use Debian 13 and switch back one version each year and once the time runs out, just move to Debian zero (removing Debian from your system) and throw your PC into the paper trash.
But to be serious: many things come together. I’m only waiting for the stable release and I will remove Windows from my system for ever. And Debian 13 seems to be a lucky number to me bringing so much great stuff and this is another one. Also KDE 6 brings lots of features I like that come to Debian (sadly not version 6.4 and 6.5). Really, I was not hyped that much for so long time and the last 2 weeks to wait for are terrible.
Yes, the fixed (new) API has existed for many years. OK, they may well now break the old API in order to force-fix all remaining code but …
what about (legacy) systems that are not being upgraded by the operator of the system?
what about those “oldest of supported hardware” systems? (are they now unsupported?)
what about embedded systems that either can’t be upgraded or that are long ago abandonware?
It seems that ext2 and ext3 are both vulnerable to the 2038 bug. Unlike forcing an API change, it may be more difficult to deal with persistent data on disk, including in archives or backups.
Anyone still using those file systems?
(However even if the operating system is 100% clean, there can be applications that store data in a database, or elsewhere, that is still a 32-bit time value.)
Microsoft transit 2005. I guess WinXP did also jumped to 64bit time. However, programs written in C could crash beyond 2038 on such old systems. Today WinXP is still a thing for some industries (offline computers) and I also know gamers with retro PCs for retro games. At least what I read about just yet. I think common users that run the latest operating system will not be affected.
I think the worst that will happen with Debian etc are not the active user systems, but the embedded systems of for example IoT-devices that will not get any update. On the other hand, those devices usually will break after some years anyway, that customers can buy a new one to keep the industries growing.
All FAT file systems use an arcane 32-bit timestamp value that is divided up into 6 x various-sized bit fields, and with a base date of Jan 1, 1980, which ultimately give a seconds value to a precision of 2 seconds and a year value that dies in 2107. (There is an extension byte that may be available and which increases the precision to 10 milliseconds. However that doesn’t help in this topic.)
NTFS has no such problem. NTFS uses a 64-bit flat timestamp value in 100 nanosecond increments, with a base date of Jan 1, 1601, and which dies in the year 60056 (so not likely to be of concern to present forum participants).
FWIW, at a quick look, SMB uses the same representation as NTFS. Therefore SMB does not introduce any new limitations. Whatever limitations, or lack thereof, in the underlying file system, they will be preserved by SMB.
This is an important consideration in an increasingly virtualised and abstracted IT environment. All of the following may cause breakage:
the underlying file system
the API used on the remote system to access the file system
the remote file access protocol used e.g. SMB, NFS.
any local API used
A fully patched, up to date, client system may still die in 2038 because you don’t even know what operating system is running inside computers that the client depends on.
So, for example, if you were using an abandonware NAS, you would want to be very careful by the time 2038 rolls around.
Good that you point this out. I bought my motherboard 2018 and thanks to AMD (and its AM4ever plattform) I could upgrade this year to a 2.5 times more powerfull computer using the same board. So I extend its life and want to past some years beyond 2030. If it contains such microcontroller which relies on 32bit timestamp …
However. I don’t expect to use it long enough. It could be relevant to retro PC users.
Well, yes, the Intel Management Engine is an additional point of failure for systems based on Intel CPUs. Worst case, your Intel computer can’t even boot regardless of the state of the operating system software that runs on the main CPUs.
According to Wikipedia, the IME runs MINIX 3 (Unix-like) on an Intel Quark x86 32-bit CPU - which in and of itself is just the kind of combination that you don’t want in 2038 - and you have exactly zero opportunity to inspect the code (the IME firmware) to see whether it relies on a 32-bit API and whether it even reads the saved time from the hardware clock and, assuming yes to both, whether that causes a severe problem.
The bug hits the hp3000 in Y2K28. The solution is to buy a 10 year patch from a 3rd party vendor.
The poor man’s solution is to to set the clock back and not care about the year. If you want compatible days-of-the-week pick the year 2000 or 1972. Obviously you can’t run a business system with dated 28 year old invoices or purchase orders. But you could still play games and your emails will have a funny date sent stamp. “Why did you take so long to reply, waaahh, waaah.” Or “I’ve missed you all these years…”
the big problem with setting the clock back isn’t that high level :
your SSL certificates simply won’t work with the rest of the world - you won’t be able to connect to virtually anything on the modern WWW without an accurate-ish clock setting
first of all, the computer might predate SSL/TLS anyway so the whole question is irrelevant
secondly, if you have access to the source code, you can probably override that
thirdly, the computer may have no internet-facing role (but you still need it to function correctly).
You don’t make clear whether your concern is “ancient computer” as server or as client.
As server there may be no problem at all. Just load a certificate with a current date and the server may present that to clients as opaque data and clients are happy. You only even have a problem if the server parses the certificate from its binary format and validates the date itself but it doesn’t have a lot of reason to do that.
Based on the number of times that certificates have expired in web servers and it is left to the client (web browser) to complain that certificate validation failed, I have my doubts that any servers are checking their own certificates.
As client, yes, you will need to override either the date/time that the certificate validation code gets from the system clock (bump it forward by decades) or, probably better, the date/time that the certificate validation code gets from the server’s certificate (bump it back by decades) - or disable the certificate date validity check completely (with some associated security risk).
Of course, if we are worried about how “ancient computer” interacts with the rest of the internet then any number of protocols could malfunction even where no SSL/TLS is involved at all.
As an example, the DKIM specification specifically points out that timestamps (encoded as ASCII strings) are not limited to numbers that would fit in 31-bits (signed) or 32-bits (unsigned). (However as noted previously, I would sincerely hope that any email that “ancient computer” sends or receives with the internet would go via a much more up-to-date internet-facing computer.)
Well, since the HP3000 neither uses nor understands SSL, there are no worries on that account. (It can only run HTTP, not HTTPS.) No SSH either, just unencrypted plain text.
It should be copacetic with the EU in that other thread, no?
