Forum

My skills were so overwhelming they ripped a hole in space and time

It’s 1970 because of that UNIX 32bit thing. But why it’s doing this I don’t know.

Quoted from Setlet

It’s 1970 because of that UNIX 32bit thing. But why it’s doing this I don’t know.

It’s the Epoch of the unix timestamp. The field has probably been recorded as null due to an error, which is read to be 0 and converted from unix timestamp 0 to a date, 1970-01-01 00:00:00.

Bring on 2038, when it runs out, and any particularly legacy computing systems really *will* start failing (imagine Y2K but it actually happens)

Quoted from Spike Himself

[…]

doubt it. yet to see any type of software to last 24 years..

That’s 24 years of new systems to come that could potentially be designed that way, right?

Quoted from Freakie

[…]

That’s 24 years of new systems to come that could potentially be designed that way, right?

It’s also 24 years for clever folks to work on a solution. I’m pretty sure the impact will be minimal given the amount of time there is to prepare for it.

Quoted from Spike Himself

[…]

It’s also 24 years for clever folks to work on a solution. I’m pretty sure the impact will be minimal given the amount of time there is to prepare for it.

32 bit integers stop at 2147483647 (sometime in 2038). If you are storing a timestamp as an integer, or treating it as one at any point, your system will fail. There’s no fix for that – database fields will roll over to -MAX_INT, integer data types will do likewise.

The fixes are to use different data types (long) which means you can go up to 64 bit integers, which gives a max time of 292278994-08-17 07:12:55 GMT.

I don’t actually expect anything to break once this is reached, it’s just a lot more likely to break things that Y2K.

Y2K did pose an actual threat. It’s just that the warnings were heard and in most cases necessary actions were taken to prevent it.