Comments on: The End Of The World http://pthree.org/2007/11/26/the-end-of-the-world/ Linux. GNU. Freedom. Fri, 21 Nov 2008 05:28:28 +0000 http://wordpress.org/?v=2.7-beta3-9791 hourly 1 By: Mike http://pthree.org/2007/11/26/the-end-of-the-world/#comment-81795 Mike Mon, 03 Dec 2007 03:14:52 +0000 http://www.pthree.org/2007/11/26/the-end-of-the-world/#comment-81795 <em>Confession time</em>: 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). <em>This has little to do with the operating system</em> (in fact, the time_t is a 64-bit value in <em>32-bit</em> 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 <em>lots</em> 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). 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).

]]> By: Matthew Kimber http://pthree.org/2007/11/26/the-end-of-the-world/#comment-80772 Matthew Kimber Tue, 27 Nov 2007 22:51:29 +0000 http://www.pthree.org/2007/11/26/the-end-of-the-world/#comment-80772 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... 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…

]]> By: Jayce^ http://pthree.org/2007/11/26/the-end-of-the-world/#comment-80731 Jayce^ Tue, 27 Nov 2007 18:11:07 +0000 http://www.pthree.org/2007/11/26/the-end-of-the-world/#comment-80731 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. 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.

]]> By: Ubuntu 7.10 64 Bit at heyko`s http://pthree.org/2007/11/26/the-end-of-the-world/#comment-80712 Ubuntu 7.10 64 Bit at heyko`s Tue, 27 Nov 2007 15:58:54 +0000 http://www.pthree.org/2007/11/26/the-end-of-the-world/#comment-80712 [...] 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 [...] [...] 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 [...]

]]> By: charly http://pthree.org/2007/11/26/the-end-of-the-world/#comment-80621 charly Tue, 27 Nov 2007 02:53:19 +0000 http://www.pthree.org/2007/11/26/the-end-of-the-world/#comment-80621 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. "... http://forum.java.sun.com/thread.jspa?threadID=5194505&tstart=105 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. “…

http://forum.java.sun.com/thread.jspa?threadID=5194505&tstart=105

]]> By: nixternal http://pthree.org/2007/11/26/the-end-of-the-world/#comment-80603 nixternal Tue, 27 Nov 2007 00:51:18 +0000 http://www.pthree.org/2007/11/26/the-end-of-the-world/#comment-80603 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 :) 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 :)

]]> By: Joseph Scott http://pthree.org/2007/11/26/the-end-of-the-world/#comment-80602 Joseph Scott Tue, 27 Nov 2007 00:48:18 +0000 http://www.pthree.org/2007/11/26/the-end-of-the-world/#comment-80602 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. 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.

]]> By: Cyrus Jones http://pthree.org/2007/11/26/the-end-of-the-world/#comment-80595 Cyrus Jones Tue, 27 Nov 2007 00:05:11 +0000 http://www.pthree.org/2007/11/26/the-end-of-the-world/#comment-80595 Cool. I didn't know this. Cool. I didn’t know this.

]]> By: TimothyP http://pthree.org/2007/11/26/the-end-of-the-world/#comment-80593 TimothyP Mon, 26 Nov 2007 23:45:41 +0000 http://www.pthree.org/2007/11/26/the-end-of-the-world/#comment-80593 Some people will make money out of this :-) Some people will make money out of this :-)

]]>