. . . for the 12th Baktun.

Yes, that’s correct: Today is the day that the Mayan calendar rolls over. Kiss goodbye the 12th Baktun and say hello to the 13th.

Because I write these posts in advance, I’m kind of gambling here that my efforts won’t be in vain, and that someone out there actually reads these words.

On the downside, if the world does end, then no one will know or even care about what’s written here. The electrons storing this information will be released back into the universe never to be collected in the same way ever again. Bummer.

Speaking of impending doom, it seems to be a recurring theme with computers. You could almost set your Mayan clock by it. Allow me to review great points of doom from my personal computer memory banks.

The PC’s Dawn of Time

The first onslaught of IBM PCs and their clones lacked internal battery backed-up clocks. When you turned on the system, you were prompted to enter the current date and time. That is, unless you bought a “Clock card,” which had the battery and automatically took care of the date and time for you.

What happened when you failed to input the date and time? Why, MS-DOS believed it to be January 1, 1980 at midnight.

That was a Tuesday.

I can remember working on lots of PCs were all the files were date-stamped January 1, 1980. That’s because few people bothered to set the time.

TRS-DOS 6 DOOM

If you’ve followed this blog for any length of time (and it’s been up now since December 2007), you know that I was once a TRS-80 geek. Trash-80. Radio Schlock. All that. Although I recognized the superiority of the IBM PC and MS-DOS back in the mid-1980s, I stuck with my Model III and later Model 4p until . . . I started programming for the latest version of its operating system, TRS-DOS 6.

In TRS-DOS 6, Radio Shack (or whomever they hired to write the OS) assigned only one byte of data in which to store the date. Two bits were used to represent the year. Being a programmer, I immediately recognized that after 1989, my computer’s operating system would be unable to properly time-stamp files or anything. Within weeks, I dumped that computer.

Y2K Bug

I don’t need to blather on about the Y2K problem, and how the world was going to end on January 1, 2000 when all the computer clocks rolled over and thought it was January 1, 1900. The media loved the scare more than any computer geeks I knew: Elevators would plummet, planes would crash, your bank statement would show negative interest. Doom!

It was a joke.

Well, the fear-mongering from the media was a joke. The Y2K issue was real. Had nothing been done about it, then there would have been problems — not disaster, but problems. Fortunately, peril was avoided.

Mayan Thing

So the Mayan calendar turns over. Doom? Probably not. My Jeep’s odometer turned over to 10,000 recently and it still runs.

While the Mayans were excellent astronomers, they weren’t very good at predicting the future. Otherwise they would have bought Netscape at 2 and dumped it at 130.

Unix 2038 Bug

Just as mortal computers suffered from the Y2K bug, Unix computers are subject to the 2038 bug. It’s kind of the same deal as Y2K, sorta.

During the year 2038 some Unix computer clocks could potentially jump back in time to Thursday, January 1, 1970. Other systems may interpret the date as 1901.

Just as with Y2K, the “Unix bug” is being fixed. I would doubt that any version of Unix sold today is affected. Only some legacy systems may cause trouble, but it’s those legacy systems that print your phone bills and so on.

Anyway, the Unix Bug is the next point of peril for all mankind. Well, unless something intervenes in the meantime. Given the 24-hour news cycle, I’d say that the odds are pretty good.