Re:Unix Year 2038 problem and the art of underestimating
by DoctorOetker on Saturday September 19, 2026 @05:34PM
(#49770310)
Why not calculate the number of bits necessary before Sol goes supernova? The clock will only be as useful as long as the local star lasts, and when different star systems get populated they or their planets will use local clocks as well.
In theory laws could be authored requiring entities to register pragmatic assumptions with foreseeable violation dates, so that they can be added to a sorted queue of assumption violations to be crossed.
Re:Unix Year 2038 problem and the art of underestimating
by mrlonglong on Sunday September 20, 2026 @08:01AM
(#49774948)
Let's be super safe and assume 128 bits will be sufficient for as long as the universe lasts. Whether humanity will still be around is a matter of debate.
Re:Unix Year 2038 problem and the art of underestimating
by pjmlp on Sunday September 20, 2026 @04:34AM
(#49773783)
We had a similar issue back in the 2000's, not the Y2K problem, rather file accesses.
One project I did in 2000 was porting HP-UX software to handle 64 bit file offsets, as it was originally written with 32 bit machines in mind, and the deployment scenario naturally evolved.
Re:Unix Year 2038 problem and the art of underestimating
by roryirvine on Sunday September 20, 2026 @05:12AM
(#49774018)
In Linux, I recall the whole Large File Support saga dragging on into the 2.4 era. It certainly wasn't universal until well after 2 GB devices had become commonplace even in consumer-level hardware, meaning that things like creating a whole disk image were impossible for several years.
There were a bunch of similar problems with hardware device support at around the same time - various BIOS, MBR, and partition size limits affecting 512 GB, 2 GB, and 4 GB disks (I think - my memory is pretty hazy).
Even further back, there was the infamous 32 MB partition limit in DOS 3.3 and earlier, which was still being sold with new machines at a time when 40 MB disks had become standard. Pretty much everyone in the late 80s had an awkward 8 MB D: drive hanging around as a result.
By those standards, the Y2038 problem has been handled ridiculously far in advance!
There are undoubtedly still issues in legacy apps around Y2036/Y2038 waiting to bite us, and further ahead there's likely to be some hangover in 2060/70 from the hacks put in place to deal with the Y2K issue. We might see a small army of centenarian COBOL programmers being paid very handsomely indeed...
In theory laws could be authored requiring entities to register pragmatic assumptions with foreseeable violation dates, so that they can be added to a sorted queue of assumption violations to be crossed.
Sol won’t ever go nova, though, so I’m not sure how one would calculate the number of seconds until that happens.
Y2038, meanwhile, is just an artifact of the limitations of older hardware.
One project I did in 2000 was porting HP-UX software to handle 64 bit file offsets, as it was originally written with 32 bit machines in mind, and the deployment scenario naturally evolved.
There were a bunch of similar problems with hardware device support at around the same time - various BIOS, MBR, and partition size limits affecting 512 GB, 2 GB, and 4 GB disks (I think - my memory is pretty hazy).
Even further back, there was the infamous 32 MB partition limit in DOS 3.3 and earlier, which was still being sold with new machines at a time when 40 MB disks had become standard. Pretty much everyone in the late 80s had an awkward 8 MB D: drive hanging around as a result.
By those standards, the Y2038 problem has been handled ridiculously far in advance!
There are undoubtedly still issues in legacy apps around Y2036/Y2038 waiting to bite us, and further ahead there's likely to be some hangover in 2060/70 from the hacks put in place to deal with the Y2K issue. We might see a small army of centenarian COBOL programmers being paid very handsomely indeed...