2036 and Y2k

[Nighttide]

2036 and Y2k

I'm sorry if this has been brought up before, but I thought it was interesting. Before I go any further, however, let me just throw out a few qualifications.

I do not believe that John Titor was/is a time traveler. However, I have been willing to suspend my disbelief because, well, I find it entertaining to no end, reading everyone?s arguments and counter-arguments and all. And the truth is I never believe anything completely, as I feel that?s always the safest route. Anyway.

I did a short search this evening (or morning, I guess) on the year 2036 which yielded some interesting results. They?re interesting because, if I remember correctly, Titor made mention of Y2K a number of times, and during my search the value 2036 came up, well, a number of times in regards to the Y2K ?problem.?

Just to toss in a Titor quote as an example, he said (as if you all need to know what he said):

Yes, the Pearl Harbor example relates to Y2K. Have you considered that I might already have accidentally screwed up your worldline?

And

That secondary objective is basically to gather as much information about a worldline based on a set of observable variables when we first arrive. Your worldline met those conditions. What amazes me is why no one here wonders why Y2K didn't hit them at all?

And

For a change, I have a question for all of you. I want you to think very hard. What major disaster was expected and prepared for in the last year and a half that never happened?

In truth, none of that means much. Now, let me present what I found relating the year 2036, from which Titor claims to have traveled, and the Y2K ?Bug.?

This site, http://www.datman.com/tbul/dmtb_034.htm, contains a technical bulletin that reads:

The problem is caused by DATMAN-DOS's action when it puts a
time-stamp on various occasions. DATMAN invokes the low-level
(BIOS) system call to retrieve the current date and time which
is being kept by the BIOS firmware. Last month, one customer
called us and alerted us with a funny behavior of DATMAN-DOS
which shows a newly created directory with the year 2036!
After some extensive studies, we confirmed that on certain
systems, the date code DATMAN receives from BIOS has either a
non-standard (or just plain buggy) date value beyond 2000,
DATMAN may pass along invalid date stamp to various internal
data structure. We are not sure how wide spread this problem
will be.

No big deal, to be sure. But moving right along?

Another message on a different site (http://wn.cyberwerks.com/1998/0184.html) also regards Y2K glitches and the year 2036:

My clock switched to the year 2036 for technical reasons. WN was running without any problems, because it's not using a clock. Even my cron-jobs seems to be running. Only the statistics became messy.

The year 2000 is no problem.

Again, no big deal. Still, kind of interesting.

And another website (http://h71000.www7.hp.com/openvms/products...conditions.html) states this:

When the EXCHANGE utility is used to transfer files between OpenVMS and RT-11 or DOS-11 systems, date problems could occur starting in the year 2004 for RT-11 and in the year 2036 for DOS-11.

Oh, and this site (http://www.netbsd.org/Ports/amiga/y2000.html):

DraCo machines are using a 40 bit hardware clock counting 1/256 seconds from January 1, 1978. This will overflow in January 2114. We plan to recommend recalibrating the base date of the clock when this date comes near without any solution from the manufacturer. Note that NetBSD, like virtually all other Unix-like systems, would need to switch to a time_t with a higher range to work after 2036.

And this site (http://rfc2626.x42.com/):

The time is the number of seconds since 00:00 (midnight) 1 January 1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this base will serve until the year 2036.

And so on and so forth. There are more, but I find it interesting that the year 2036 is mentioned in regards to computer "glitches" similar to how the year 2038 is mentioned in regards to, well, the Unix thing that Titor supposedly intended to fix.

There?s probably something I?m missing here, or maybe it?s already been discussed and is common knowledge, but it may be no coincidence that the man claiming to be Titor chose the year 2036 as the starting year of his journey through time (in telling the story). I don?t know. I?m just trying to think outside the box, maybe as a storyteller, and how certain things may be linked together. In this case, gathering ideas for a good time travel end-of-the-world adventure yarn, and using two separate dates that seem to be correlated in regards to a major "plot point" in the story. Of course, I'm not trying to prove he was real or not, one way or the other, I'm just trying to present new ideas. I guess.

At any rate, take from this what you will, or nothing at all, as I browse the Internet for more interesting stuff.

 

[Sovaka]

Re: 2036 and Y2k

I am not sure if this has any relevance what so ever, but I will put it out there.
One day I was extracting a rar file and when the file finished extracting, it timestamped
1/01/2098 at 12:00am
Having seen that straight away, I checked my computer clock and it read the proper date. Don't know why it timestamped 1/01/2098 at 12:00am. :|

 

[Timescholar]

Re: 2036 and Y2k

I recall reading somewhere that 2036 (or 2038?) is a known unix timestamp bug where Unix clocks end. It would simply reset to whatever year represents 00000000000000000. The "1" bit is there, just it has no place to go, so it's dropped off. It's a common bug in many programs actually, where the programmer doesn't allow for the fact that a value CAN reach, or go beyond the maximum. (Another is memory usage at the time, and no one updated it).

Different software and operating systems will keep pushing the end date further and further. Back in Win3.1, I think the max was 2020, or 2027.

 

[Omega]

Re: 2036 and Y2k

I think everyone is reading too much into this titor stuff its all crap, get real people.