Image of the glider from the Game of Life by John Conway
Skip to content

The End Of The World

Year 2038 visualizationThis has been discussed a bit lately, and I thought I would throw in my two cents. Why would you want to run 64-bit versus 32-bit on your personal computer? Simple, your 32-bit operating system contains a ticking time bomb (no pun intended) that could likely explode causing problems for you creating headaches.

It is known as the Y2K38 bug, and it comes to life Tuesday January 19 2038 at 03:14:07. If you're not running 64-bit, your computer, or embedded system, will likely show the next date following as Friday December 13 1901 at 20:45:52. This is due to 32-bit systems running that are using the UNIX epoch timestamp. Is this a problem? Most definitely! You probably will not notice it on your laptop or desktop for casual use now, and you probably won't notice it in 31 years, as we will most likely be past 32-bit, and possibly even 64-bit when it comes to our personal machines. After all, look at the past 30 years and how far we've come. However, look at embedded systems, such as microwaves, tvs, routers and thin clients. Many are 16-bit and even 8-bit systems, not to mention 32-bit. Look at code. I have heard of 8-bit binaries in production that were written 20 years ago still in production. Will 32-bit code still be in production 31 years from now? Very likely.

So, to add to the arguments of whether to run 64-bit or run 32-bit, I suggest running 64-bit just in case you write software that may be in production in 2038. I also suggest running 64-bit to prevent existing software from having issues in projecting future dates past January 19 2038. So there you have it. Run 64-bit.

{ 9 } Comments

  1. TimothyP | November 26, 2007 at 4:45 pm | Permalink

    Some people will make money out of this 🙂

  2. Cyrus Jones | November 26, 2007 at 5:05 pm | Permalink

    Cool. I didn't know this.

  3. Joseph Scott | November 26, 2007 at 5:48 pm | Permalink

    This really doesn't haven't anything to with 32 versus 64 bit operating systems. This has to do with the time_t struct being 32 bit. A program that casts time_t to 32 bit on a 64 bit operating system will still have problems. The flip side is also true, a 32 bit operating system can specify a 64 bit time_t struct to deal with the issue.

  4. nixternal | November 26, 2007 at 5:51 pm | Permalink

    So what you are saying is that operating system vendors have 30 years to get their stuff straight? 🙂 Hopefully in 30 years we will have working 64bit desktops, you know what I mean, everything builds and compiles on them just fine w/o running my 32bit chroots.

    @Joseph: So I wonder who commits the first patch for an issue not due for another 30 years 🙂

  5. charly | November 26, 2007 at 7:53 pm | Permalink

    glad you advise the community :<),
    it kept me out of sleep for a while :o)

    SOLARIS has fixed this!!, maybe we should all move to solaris ?

    froms solaris site
    ...." java.util.Date uses 8 bytes (a long) for millis since 1/1/1970, which is good until about the year 290,000,000. "...

  6. Jayce^ | November 27, 2007 at 11:11 am | Permalink

    As Joseph mentions above, just changing to a 64-bit desktop/distro will *not* fix the problem. You have to take every library, language, and bit of code that has the timestamp stored as an 32bit int (or struct) and modify them to use a larger bit of memory. 32-bits can get around it just fine, if they are willing to do it in more than one processor step (which is why they haven't until now).

    But just recompiling won't change the existence of that limitation. You gotta recode first.

  7. Matthew Kimber | November 27, 2007 at 3:51 pm | Permalink

    So have you tried it out on your microwave yet? Do microwaves even hold the date? I guess it would depend on how much money you spent. Perhaps I should try it on my VCR...of course that is probably a 16 or even 8-bit machine. Hmmm...

  8. Mike | December 2, 2007 at 8:14 pm | Permalink

    Confession time: I recently committed this sin in a production system for a bank's lending-systems brokerage service. It's not too critical: this is code to delete old records, where the timestamps are in Java time (msec since 1970) -- one of the perils of using closed-source boxed solutions from vendors who don't care about customers...

    Anyway,my code checks for the wrap-around and just stops working after then (resulting in old data no longer being purged).

    This has little to do with the operating system (in fact, the time_t is a 64-bit value in 32-bit Linux too, not just in 64-bit Linux, Solaris or MacOS, plus Windows' equivalent doesn't have this bug, but one of it's own...).

    In my case, this bug persists because I'm doing date arithmetic using a built-in function in MS SQL-Server 2000 which uses 32-bit integers. My actual code doesn't have the bug either (appart from running in MS-SQL Server...): it's in DATEADD and DATEDIFF. The only solutions are:

    1) M$ fix these functions (maybe they'll do it, if they're still in business in 30 years), or
    2) replace the built-in functions with my own (I expect my own will have a lot of issues that would need extensive testing, already done for DATEADD/DATEDIFF.), or
    3) Replace MS-SQLServer with a different vendor's RDBMS, which doesn't exhibit this problem (depends on what the PHBs decide, unfortunately...), or
    4) Ignore it. Our system doesn't have a 30 year life time. But then, this was the same "solution" that many coders writing COBOL financial systems code took in the 1960s...

    There has to be lots of places this crops up. My worst fear is that, because Y2K was such an expensive non-event, this bug and others like it will just be ignored, since Y2K never happened. My hope is that, like in my case, the implications are not life threatening and pretty easy to spot (since I've flagged it in comments, and when it stops working, it'll be noticeable that data aren't being deleted).

  9. Spider | January 4, 2009 at 7:03 pm | Permalink

    i love this site.

{ 1 } Trackback

  1. Ubuntu 7.10 64 Bit at heyko`s | November 27, 2007 at 8:58 am | Permalink

    [...] in den letzten Tagen das Thema Ubuntu 64 Bit auf Planet Ubuntu vermehrt diskutiert wurde habe ich mir auch mal die 64 Bit Version von [...]

Post a Comment

Your email is never published nor shared.