Okay, so I was looking around for something on here to look at for a few laughs to relieve some boredom, so I found the first part of ToU, which had a very strong instance of the Y2K bug, this can be seen as the first post listed here. A few minutes ago, I was trying to access Haze's Hideout, and I found that all the comments had the Y2K bug. This can be seen here.

Oh, and while we're on the subject of Haze's Hideout, the Alternate Link is broken.

EDIT: Oh, and unless you add /blog/ to the end of the link, the main site is innacessable. It might be because I have an Antivirus that knows that people host Trojans on Dutchfurs(Apparently, someone hosted a Trojan on Dutchfurs today).

That's not the Y2K bug, but probably something else. The Y2K bug was specifically a result of storing the date as separate day, month and year fields, but only storing the last two digits of the year. This meant that the date went 31/12/99 21:59:59 -> 1/1/00 00:00:00, or 31/12/1999 -> 1/1/1900.

Several programming languages store the time in a different format: as the number of seconds since the start of 1970. In some cases of corruption, like what probably happened in that JCF post, the time can wrap back to 1970.

Well, that is fairly similar to the Y2K bug in that the Dates/times are displayed wrong due to the way it's programmed. Do you think it's possible to fix any of these?

It's only similar in that it affects the same thing (more info). It's unfortunately not fixable, if the time is shown as 1970 it usually means the original timestamp is lost and the site is assuming a timestamp of "0".

Same goes for the dates on the Haze's Hideout comments, apparently for some reason the wrong number is stored as their timestamp, and there's no way to find out what it originally was.

Ah, Okay. Oh well.

Originally Posted by Stijn

Same goes for the dates on the Haze's Hideout comments, apparently for some reason the wrong number is stored as their timestamp, and there's no way to find out what it originally was.

I can safely assume they were posted in the past. Even more specifically: somewhere between the date the article was made and the time this thread was made.

At 03:14:08 UTC on 19 Jan 2038, 32-bit versions of the Unix time stamp will cease to work, as it will overflow the largest value that can be held in a signed 32-bit number. Before this moment millions of applications will need to either adopt a new convention for time stamps or be migrated to 64-bit systems.

Someone told me that this day will be the apocalypse.