Y2k for the Linux world is the year 2038

[flibberdipper]

It's partly because of mans confidence/arrogance and partly because so far we've managed to avoid major disaster because of prevention, so the standard response is simply "Oh we fixed it before, we'll do it again".

But if we don't fix it then all hell will break loose, see my post above for a possible scenario that could very well happen if we don't protect against it.

One fix we can do is push an update that resets to the 32bit integer to start from a much later time, so instead of resetting to 1/1/1901 it could set it to 2001 and count up from there while keeping the current date, and that would give us roughly another 100 years or so to completely replace every machine this affects. If you're a bit confused by my poor explanation it's basically this.

Currently the 32bit integer starts at 10000000 00000000 00000000 00000000 which to the computer equates to 1/1/1901 and would count up to 31/12/2038 and then reset to 1/1/1901, if we set that same binary number to equal 1/1/2001, and leave it to continue counting with the current date it wouldn't reset until around 31/12/3038, but that might not work for all systems and could break the software being run. (I hope you get it, I know what I mean, but I don't know if I explained it correctly)

 

If this can actually be done, then that is awesome. I actually understood this, which is impressive. Good job, good sir.

[patrickjp93]

For those arguing about bit-width and counting systems, here is some perspective. The maximum positive number you can represent with 32 bits is (2^32)= 4294967295 (because 0 is one of the represented numbers). 

This number happens to be the number of bytes a 32-bit system can address in RAM (Intel uses some address extensions in the 32-bit architectures in order to mitigate this).

This happens to be the number of bytes in 4 GiB (Gibibytes), the amount of memory in a 4GB RAM stick.

64-bit machines have (2^64) addresses. This happens to be 18,446,744,073,709,551,616 bytes. 18 exbibytes!

We will not be addressing this much RAM for at least a decade even in the largest supercomputers. There is absolutely no point in 128-bit computers.

[beefalo]

It's partly because of mans confidence/arrogance and partly because so far we've managed to avoid major disaster because of prevention, so the standard response is simply "Oh we fixed it before, we'll do it again".

But if we don't fix it then all hell will break loose, see my post above for a possible scenario that could very well happen if we don't protect against it.

One fix we can do is push an update that resets to the 32bit integer to start from a much later time, so instead of resetting to 1/1/1901 it could set it to 2001 and count up from there while keeping the current date, and that would give us roughly another 100 years or so to completely replace every machine this affects. If you're a bit confused by my poor explanation it's basically this.

Currently the 32bit integer starts at 10000000 00000000 00000000 00000000 which to the computer equates to 1/1/1901 and would count up to 31/12/2038 and then reset to 1/1/1901, if we set that same binary number to equal 1/1/2001, and leave it to continue counting with the current date it wouldn't reset until around 31/12/3038, but that might not work for all systems and could break the software being run. (I hope you get it, I know what I mean, but I don't know if I explained it correctly)

 

I think your math is a little off here. A 32 bit integer can count to ~4 billion and according to the gift in the OP it is being used to count every second as an integer, meaning a 32 bit integer can count 2^32 seconds or about 136 years. Switching to a 64 bit integer would obviously solve the problem as it could count ~4 billion squared seconds but it won't solve the real problem. There is a reason we don't need 64 bit for everything. Small integrated systems have no need to store data in 64 bits and it would be a waste of money to use 64 bit processors in everything.

 

The simplest solution would probably be to reset the initial date every time the time_t integer reaches it's maximum and instead of having time_t values equate to a date, have it be a count from some other stored date value.

[AxelRantila]

The simplest solution would probably be to reset the initial date every time the time_t integer reaches it's maximum and instead of having time_t values equate to a date, have it be a count from some other stored date value.

That is IMHO not a good long-term solution. What if you have a system that needs to be running 24/7 and you don't have the option to reset it?

[Ashley]

by that time I would hope we have moved on to 256 or 512 bit. if not 1024

Keep in mind how long 16 to 32 took, and that we haven't gone to 64 universally in software yet. I doubt we'd be at 512, and especially not 1024. Most data doesn't need massive word size. We'll probably just have much better multi-precision hardware acceleration, for the limited cases we need it.

 

Keep in mind word size, memory size, and bandwidth are all different things.

[Robin88]

I think your math is a little off here. A 32 bit integer can count to ~4 billion and according to the gift in the OP it is being used to count every second as an integer, meaning a 32 bit integer can count 2^32 seconds or about 136 years. Switching to a 64 bit integer would obviously solve the problem as it could count ~4 billion squared seconds but it won't solve the real problem. There is a reason we don't need 64 bit for everything. Small integrated systems have no need to store data in 64 bits and it would be a waste of money to use 64 bit processors in everything.

 

The simplest solution would probably be to reset the initial date every time the time_t integer reaches it's maximum and instead of having time_t values equate to a date, have it be a count from some other stored date value.

I know it's off, it's just the easiest way to explain it (I didn't actually run the maths on it, I just shifted the dates forward by 100 years) and switching to 64bit would give us a date millions of years into the future, but it's not that simple for embedded system to use a 64bit integer without rewriting the code for the embedded system to use that 64bit integer and doing so could potentially breaking everything, and while it doesn't really make sense for many embedded systems to use 64bit, it is so cheap to use 64bit systems that we might as well eventually replace the current systems over time and just jerry rig a fix in the meantime. and 32bit actually supports 4billion unique numbers if it's an unsigned integer, and 64bit supports 18 quantillion unique numbers, not 4billion, so the date is something like over a billion years for a true 64bit system

Thank you though for giving me the actual number of years a 32bit integer can count to, I actually wasn't sure how many it was

And besides, the issue isn't about simply updating the systems, it's that most simply can't be updated in the first place, many don't have rewritable firmware/software, many use ROM storage and the amount of RAM is so tiny they might not have the resources spare to store the code required to fix the issue properly.

[Guest]

by that time I would hope we have moved on to 256 or 512 bit. if not 1024

That's a dumb idea... 

[Bensemus]

there is no reason any time soon to go over 64 bit, it would be a waste of space and resources.

Having the clock reset in a few decades seems like a good reason to switch. Not the whole program, just the part responsible for time keeping.

[Deletive]

by that time I would hope we have moved on to 256 or 512 bit. if not 1024

We probably would be on either quantum or haven't moved at all.

[Linus_torvalds]

It's a bigger number. Bigger = better

That does not work, because console fan boys say resolution is just a number, 1080p PC < 900p conmsole I hate when console fan boys say that. 

 

hope in 2038 there will only be PC.

[dfsdfgfkjsefoiqzemnd]

I'm not worried, by then my bunker will be finished and stocked with enough supplies to last me a lifetime.

[Dabombinable]

That's just weird. Why will the OS have a problem when its the BIOS that handles the clock? I know from experience that my old 1992 386 was able to keep running without a hitch through 1999-2001. People panic over nothing.

[Opcode]

Change the signed integer to an unsigned integer. That prolongs the issue until 2106. We'll all be dead by then so let someone else fix it.