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.
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...
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.
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.
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...
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.
Pretty sure a 64-bit integer gets us to the death of our sun with several powers of 10 left over.
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.
This one was pretty fun to discuss. Nobody is ever going to need more than 640k of RAM.
We talk about the Year 2038 problem, Y2K, DJ10K and many more bugs of this nature
This was fixed for all my UNIX systems in 2012.