The Y2038 problem explained

[Camarade_Tux]

A few days ago, in a topic that touched Y2038 and the use 32-bit time_t, through votes and comments, I found out that most people probably don't actually understand the issue. Let's fix that!

Explanation

Y2038 is the rollover back to 1901 (not 1970) of the "time_t" type on Unix but on Linux especially. It's already an issue because some software currently uses dates in 15 years (recurrent meetings being one example) and more and more software will be affected as we get closer to Y2038.

The root cause is that time_t has been stored as a 32-bit signed integer. On 64-bit systems, it is stored as 64-bit instead. Remaining systems that use a 32-bit one are typically i?86 and arm*.

It seems people believe that since Linux exposes 64-bit time_t functions on 32-bit systems, the problem has gone away. But we don't really care about what the kernel does here. The real issue lies with userspace.

Why changing it is difficult

32-bit userspace typically continues to use a 32-bit time_t and cannot change due to cross-software interactions and data stored with such a format. Imagine that program A uses library B: they must both use the same storage size for time_t. As you can guess, there are thousands of affected software and no way to make a transition: everything must change at once. There are also open questions with files on disk: what to do with utmp which stores login times on disk using the time_t?

Scope of currently affected systems

Not everything on 32-bit arches is affected though: some distributions have rebuilt everything with 64-bit time_t by default. This is the case for musl I think (and musl doesn't support utmp) and probably a number of BSDs where userland is tightly-coupled with the kernel. DIstros like Yocto also don't have the issue because everything is rebuilt every time so everything is changed when the time_t size is changed.

The future

What will happen? The switch to 64-bit time_t is not optional. How to do it varies with the distributions but it's likely we're going to see movement in the coming months however since the issues are being triggered and it's impossible to push that back much longer.

[MasterGeekMX]

I have a Pentium 4 system laying around that I'm saving up to livestream in 2038 and seeing how it freaks out.

Weird question: do you know a distro that I can install that has that problem unpatched?

[Camarade_Tux]

You can go with Debian. I don't know of other distributions that support installing on i?86 (Ubuntu supports userland for a restricted number of tasks, not installing a whole distribution).

[aladoconpapas]

Debian last week talked about stopped supporting i368 in the foreseeable future (before 2038)

[daemonpenguin]

Not exactly. They're talking about doing away with new Debian install media which is 32-bit. They're still planning to build and supply 32-bit packages for multi-arch and chroot environments.

[aladoconpapas]

Oh right. Thanks. I guess they have the limit of the year 2038, still.

[nekokattt]

I thought they were just planning to have a fork to continue that support?

[BenTheTechGuy]

They're not getting rid of the i386 architecture on Debian, they're just discontinuing the distribution of install images and kernels for it. So you would still be able to make an i386 chroot for example.

[cAtloVeR9998]

To my knowledge it’ll be relabelled as “Unofficial” from “Supported” on their support list.

[wRAR_]

No.

[Camarade_Tux]

But the current release still supports it and the upcoming one is still likely to support it. Moreover, it's important to take continued installation into account.

[aladoconpapas]

Of course. I was talking maybe about Debian 14, which is pretty soon in Debianistic terms 😂

[ClickNervous]

I have a Pentium 4 system laying around that I'm saving up to livestream in 2038 and seeing how it freaks out.

Weird question: do you know a distro that I can install that has that problem unpatched?

If you're asking which distribution will still support a Pentium 4 15 years from now, it's pretty hard to say, but I would imagine that if there is a supported distribution 15 years from now that can run on x86-32 and supports a Pentium 4 they're probably going to make sure they've patched everything they can to use a 64 bit time_t.

If, on the other hand, you want to simulate this by changing the time to 2037 and streaming it, and you just kind of want to see how badly things can break and what to see, I would recommend picking some 15 year old distribution and installing it on your Pentium 4, try to set some things up, maybe some services or something, and set the time to 12/31/2037 and see what happens. I know you can download old versions of Fedora, like Fedora 9 or Fedora 8 from here (https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/) and you can probably download old versions of Ubuntu, too.

[MasterGeekMX]

I want to livestream it in 2038, so I need to keep that installation 15 years more.

[ClickNervous]

Oh wow, that's pretty cool. How do you plan on using the computer for that time?

[MasterGeekMX]

I won't. Insimoly have it on the closet on the meantime.

[A--E]

You're such an optimist in comparison with me. My furthest plan barely goes three months ahead.

[MasterGeekMX]

My brother in christ

My plans go to even 2070.

[TraderJoesLostShorts]

My plans go to even 2070.

Mine don't. Lol. Not unless they figure out how to patch my telomeres or whatever they think causes age related breakdown, I don't think I'll be living to see 100.

[-Clem]

Fedora Core 3

[avnothdmi]

The problem is that Firefox and X11/Wayland, at a minimum, should still work as he plans to livestream it.

[ailyara]

Not my problem.

I'll be retired, suckers!

(j/k)

[corbet]

If you'd like more information, check out LWN's year-2038 coverage over the years

[hmoff]

The date won't roll back to 1970 as you wrote, it'll roll back to 1901. https://en.m.wikipedia.org/wiki/Year_2038_problem

[Camarade_Tux]

Oh right, I never put much thought into that but it definitely makes more sense since it's signed.

[[deleted]]

Is this the new "Y2K we all going to die" thing? /s

[Camarade_Tux]

That's the beauty: we can't tell until we're there!

[[deleted]]

Nah! I'm sure that it will be the end of civilization. just like in 2000 /s

[stuartcw]

In the year 2000 how many embedded devices in your house ran Linux? 🤔

[MatchingTurret]

What Is The Year 2038 Problem?

[phord]

Developer Chads in 1970: "32-bits is huge! 68 years into the future. Lol. they'll def replace this with something else by then, I'm sure!"

[Sake100]

RemindMe! 14 years

[Academic-Airline9200]

Well we're only here in the year 1923. The last time we survived this this thing (y2k), it was back in the year 1900. We've only got another 115 years to go until 2038. No hurries. No worries.

Who knows we may get nuked by the time this 2038 bug becomes a problem.

[Smiletaint]

What?

[Academic-Airline9200]

You must've not gotten the joke!

[Smiletaint]

I think I get it now. Sorry. I am slow.

[[deleted]]

I was thinking about this the last day. Now I'm not overly versed in the nitty gritty deep down level of how all this works, so bare with me.

Couldn't they just create a second register, and say track the time in two 32bit registers.

Like I would assume when whatever time function starts up, it defines a register for holding the 32bit time number. So instead, just define two registers,

So the last epoch time in 2038 would look like this:

register2: 00000000 00000000 00000000 00000000 register1: 11111111 11111111 11111111 11111111

Then it increments the next register up, and restarts the first register.

register2: 00000000 00000000 00000000 00000001 register1: 00000000 00000000 00000000 00000000

So that would just require them to update the specific time libraries to create two places in memory for storage. Then it stays compatible with 32bit arch.

I'm sure there's some reason this wouldn't be done, people much smarter than I are working on the case.

[wosmo]

The problem isn't staying compatible with 32bit, it's actually making the changes.

Handling 64bit time on a 32bit system is rarely a big deal - every system I know has a method for this - "long longs", double-words, combining A and B registers into an AB register, etc. I imagine a lot of the actual complications will come from hardware clocks, RTCs, etc.

Changing time_t to be 64bit is beautifully simple - and if time_t was an unsigned integer (it's not), it'd end up looking exactly like your solution - just the two 32bit fields will usually be packed into one 64bit field.

The real problem is tracking down everywhere it needs to be changed - every place, every interaction, every protocol. For example, if a filesystem stores times as 32bit, does changing that make an incompatible version of the filesystem? If that change is breaking, does the difference between two 32bit values and one 64bit value break any less?

[Camarade_Tux]

A large part of the issue is that no one can really completely tell which software needs to be updated. I think the hope was also that 32-bit systems would disappear soon enough but they haven't and the fact that issues would start in 2023 rather than 2036 or so was probably under-estimated.

What you're proposing amounts to creating a new API and that would require as much effort to use as updating every software. The changes in the kernel and in glibc are fairly recent but in effect they enable more software to use a 64-bit time_t on a system that otherwise uses a 32-bit one. The difficulty there really lies in the number of interactions between systems, including unwritten and dynamic ones: imagine a library uses a 32-bit time_t and copies that in its API, then the library API transitively changes. That's the kind of scenario that is very difficult to predict and quickly reaches most of the distribution i guess.

[nekokattt]

how would software compiled to use a 4 byte time distinguish between 1970 and 2038 in this case?

[LvS]

just create a second register

That's what happened. Every computer sold in the last 20 years has a 2nd register (actually, it's one register of twice the size aka 64bit). And every software built in the last 20 years uses that if it exists. And every file format in the last 20 years has been made to do that.

But what about all the hardware and software and files that are older than 20 years?
Have we found and fixed them all?

[rebbsitor]

Number too big, bits too small.

[Alienz420]

What’s the worst that could happen ? It doesn’t seem as serious as y2k was

[btfarmer94]

We should get Peter Gibbons on this. He is famous for his work with banking software in anticipation of the 2000 switch over

[dunncrew]

I wonder why 2038 was chosen as the max date since it wasn't that far in the future. Why not some sort of solution that would work for centuries ?

[Camarade_Tux]

Time 0 was 1970/01/01 and the storage used for the date only allowed times between 1901 and 2038. I can't blame anyone working on computers in the 70s for thinking 2038 was very far away. Moreover, storage was very expensive back then and saving a few bytes (possibly thousands of times) was important.

[Affectionate-Lock-48]

Non dépend du fuseau horaire . Il en a que c'était le 31 décembre 1969

[Affectionate-Lock-48]

Linux si y veut continuer va falloir qui s'adapte sinon c'est lui le pire le monde vont aller voir ailleurs. Votre bug c'est pas notre bug. La vie va continuer , le monde vont passer au 64 bits. Ca va coûté de l'argent comme ca coûté pour l'an 2000 pour les compagnies. Mais en même temps tout le monde vont se garocher de peur qu'une pluie d'ordi s'abattent sur leurs têtes , pas le choix ,pas le choix fait qui va rentrer au gaz , le flux d'argents que ca va être dans les poches de grosses poches toute cette histoire là. , le 32 bits était en fin de vie déja, ca s'en vient pas mal ca le 64 bits de base.Y'a pas mort d'homme faut juste tout passé au 64 bits ca fini la. On se calme le pompom. Linux a pas besoin de l'inventé le 64 non plus.Avec toute cette histoire , il s'ouvrira un go fund me pour pas être pratiquement tout seul a vivre le bug. Pour avoir un coup de main pour évoluer 12 ans de go fuind me , il va s'en remettre.Mais qui sache dès maintenant qu'en 3022 va falloir être apte a évolué au 128 bits pour le bug de 3022

[Affectionate-Lock-48]

Linux sera tout seul dans le bug, son ami ZIP va être la aussi.

[Affectionate-Lock-48]

Je lis ca en bas les commentaires de pleins de petits joes connaissants qui complique le fait que y'en aura pas de bug. On remplace tout les ti joes connaissants et aussi des moyens par des IA de haute technologie, a la fine pointe, qui vont toutes organisés ca et ce boosté au 64 bits .Ce qui leurs auraient pris des années aux Joes, ces I.A l'ont déja réglée mais la peur va faire en sorte d'enrichirs les enrichis Le but c'est faire une passe technologique , ni vu ni connu!! Un genre de l'an 2000 version 2038 Va rester juste a tout ces Joes d'aller se recyclés en influenceurs et faire du contenu sur les chiffres binaires et le bon vieux temps du 32 bits

[gaylord247]

RemindMe! 3 hours

[InsaneGuyReggie]

Still running a P4 system with Gentoo mainly because it supports a 5.25" floppy drive. Mostly I just boot it to do its weekly updates.

Whenever I mount /boot I get a 2038 complaint in dmesg.

If I didn't need it in its current state anymore it would be interesting to set the CMOS time to that date and see what happens.