Could John Titor and Y2K or Y2K38 be connected, or are we in for something worse?

[Yuris]

So, recalling some details about John Titor, an alleged time traveler from the year 2036, who returned to 1975 to take an IBM 5100 to “recode” UNIX by fixing an alleged bug.

In principle, Y2K (Year 2000 problem - Wikipedia) was just a software error, the big companies expecting the world to end in the year 2000, not considering the year in 4 digits, but in 2, it was solved.

But Y2K38 is completely different and depends on the architecture of the systems and the type of data. It basically consists in the fact that most systems store and use calendar data in the number of seconds from January 1, 1970 UTC (UNIX Timestamp). This means that on 32-bit systems, the limit of this number would be the size of the integer (2147483647) which would represent the date Jan 19, 2038 03:14:07 UTC.

Although over the years quite a few measures have been taken both on the software and hardware side, 64-bit has become a “normality”.

So, somehow the years close to this, 2036 and 2038, could be connected, or is something much worse waiting for us? What do you think ?

Year 2038 problem - Wikipedia

en.wikipedia.org

 

[Cosmo]

2036 is probably the “panic” date when a lot of terrible development teams realize they’re on borrowed time. Kids that are preteens today will be the ones fixing this, so hopefully we won’t have devolved into some version of Idiocracy, I’ll be 55 by then and living off grid

As far as Titor goes, do you know what bug he was supposedly fixing that could only be solved with a 5100? It’s been a while since I studied that aspect of the story, I can’t remember if it was something he mentioned specifically.

What is the “something much worse” you have in mind regarding 2036? I don’t think there will be any singular event, it’ll be a slow march. There was a quote from a 4chan user that said something along the lines of things will continue to get more expensive, freedoms will slowly become more constricted, life will get harder over time but there won’t be a defining explosive event that ruins us.

 

[Yuris]

I don’t think he mentioned anything too detailed about that bug, but Y2K38 seems the most plausible cause.

However, supposing the theory explained by him, somehow his simple presence caused some of his “predictions” to stop happening or to have a very long delay.

By something much worse I mean a vulnerability directly from UNIX, which could affect systems on a large scale, being exploited by the wrong people.

 

[Cosmo]

I agree that Y2K38 is a plausible cause and could have major implications if not addressed. As far as Titor’s bug goes, it’s possible that its complexity required an IBM 5100 because of its unique architecture or capabilities. It sounds like you’re concerned about the possibility of a vulnerability in UNIX being exploited on a large scale, which is certainly something to be aware of. Hopefully the development teams are aware of this potential issue and will take measures to fix it before 2036 arrives.

 

[Darby]

If you recall, the Y2K “problem” was mostly an Internet meme that turned into near panic - for no good reason. The problem with the Y2K date integer overflow was a known issue that was being addressed as far back as 1970. They had 30 years to work the problem. Why 30 years? Because home mortgages and long-term US and corporate bonds had 30 year terms. Starting in 1970 computers that were using the six digit “short date” format (mm-dd-yy) started to experience integer overflows when calculating payment and interest schedules 30 years out into the year 2000. All the real work that had to be done had little to do with financial institutions. It was SBC (single board computers) in embedded systems that were designed to last for many decades with no maintenance. The SBC’s were “buried” deep into the structure of large devices such that it was difficult to the range of impossible to get to. In the end Y2K turned out to be a nothing burger.

The Unix date overflow issue was discovered at about the same time. We’ve already had 50 years to work on it. We really don’t need another Y2K panic - which BTW was the genesis of the TItor Saga. He originally used his time travel tale to start a panic over Y2K on Art Bell’s Coast-2-Coast AM show.

 

[carscientist]

I think the go-to solution for y2k38 is just to add a line of code that says “oh yeah and also its not 1970”, don’t wanna be a buzzkill but it will probably not be a problem

 

[JudasTitor]

So, recalling some details about John Titor, an alleged time traveler from the year 2036, who returned to 1975 to take an IBM 5100 to “recode” UNIX by fixing an alleged bug.

In principle, Y2K (Year 2000 problem - Wikipedia) was just a software error, the big companies expecting the world to end in the year 2000, not considering the year in 4 digits, but in 2, it was solved.

But Y2K38 is completely different and depends on the architecture of the systems and the type of data. It basically consists in the fact that most systems store and use calendar data in the number of seconds from January 1, 1970 UTC (UNIX Timestamp). This means that on 32-bit systems, the limit of this number would be the size of the integer (2147483647) which would represent the date Jan 19, 2038 03:14:07 UTC.

Although over the years quite a few measures have been taken both on the software and hardware side, 64-bit has become a “normality”.

So, somehow the years close to this, 2036 and 2038, could be connected, or is something much worse waiting for us? What do you think ?

Year 2038 problem - Wikipedia

en.wikipedia.org

 

[Num7]

I don't think it's gonna be a problem either. Same here.

But I'm sure it'll be quite the buzz anyway. Welcome to Y2K v2.0.