Matt
New Member
Long read, but interesting!
Source: http://www.readwriteweb.com/archive...in_30_years.php
Have you heard the latest doomsday scenario? In thirty years, the internet will stop working! Apparently, a bug similar to the millennium bug will affect Unix-based systems, like those that run the tubes, in the year 2038. The bug, being dubbed the "2038 bug," arises because Unix-based systems store the time as a signed 32-bit integer, in seconds, from midnight on January 1 1970. And the latest time that can be represented in that format, by the Posix standard, is 3:14 AM on January 19, 2038. After that, times will wrap around and be represented as a negative number.
And then what happens?
Programs will fail, of course. Since they will see times not as being in 2038 but rather in 1901, erroneous calculations and decisions will occur. (It's true, I checked Wikipedia!)
We've actually seen fallout from the 2038 bug already, back in May of 2006 when the AOLserver web server software crashed. The software was designed so that database requests would "never" time out. Instead of assigning a "0" to the timeout, the software specified a timeout date one billion seconds in the future. One billion seconds (just over 31 years 251 days and 12 hours) after 21:27:28 on 12 May 2006 is beyond the 2038 cutoff date. The system calculated a timeout date that was actually in the past, got confused, and crashed.
The bug even affected the Mars Rover!
By 2038, it's likely that many of the susceptible machines will have been decommissioned before the critical date occurs. However, legacy systems and embedded systems could still be affected. These may include process control computers, space probe computers, embedded systems in traffic light controllers, navigation systems, routers, gas pumps, etc. It may not be possible to upgrade many of these systems, so they will need to be replaced.
I'm a Programmer - What Can I Do?
Test your code or use utilities such as the FakeTime Preload Library.
See the programming recommendations from The Open Group (formerly X/Open), which maintains the Unix specification and trademark.
If you're working with Open Source code, this free library may be a useful reference for patching existing code for high-accuracy longterm time calculation.
Read the Solutions to the Year 2000 Problem by Steve Manley. Many of his suggestions can be applied to the 2038 problem, too.
Keep tabs on any recent updates on the 2038 Bug web site
(Source: the 2038 FAQ)
The End?
Before mass hysteria sets in, let's all remember that we have years, decades even, to deal with this latest programming glitch.
And as for the internet?
Well, I'm pretty sure that self-improving Artificial Intelligences will be running the world by then, so we probably don't need to worry too much about this.Source: http://www.readwriteweb.com/archive...in_30_years.php
Have you heard the latest doomsday scenario? In thirty years, the internet will stop working! Apparently, a bug similar to the millennium bug will affect Unix-based systems, like those that run the tubes, in the year 2038. The bug, being dubbed the "2038 bug," arises because Unix-based systems store the time as a signed 32-bit integer, in seconds, from midnight on January 1 1970. And the latest time that can be represented in that format, by the Posix standard, is 3:14 AM on January 19, 2038. After that, times will wrap around and be represented as a negative number.
And then what happens?
Programs will fail, of course. Since they will see times not as being in 2038 but rather in 1901, erroneous calculations and decisions will occur. (It's true, I checked Wikipedia!)
We've actually seen fallout from the 2038 bug already, back in May of 2006 when the AOLserver web server software crashed. The software was designed so that database requests would "never" time out. Instead of assigning a "0" to the timeout, the software specified a timeout date one billion seconds in the future. One billion seconds (just over 31 years 251 days and 12 hours) after 21:27:28 on 12 May 2006 is beyond the 2038 cutoff date. The system calculated a timeout date that was actually in the past, got confused, and crashed.
The bug even affected the Mars Rover!
By 2038, it's likely that many of the susceptible machines will have been decommissioned before the critical date occurs. However, legacy systems and embedded systems could still be affected. These may include process control computers, space probe computers, embedded systems in traffic light controllers, navigation systems, routers, gas pumps, etc. It may not be possible to upgrade many of these systems, so they will need to be replaced.
I'm a Programmer - What Can I Do?
Test your code or use utilities such as the FakeTime Preload Library.
See the programming recommendations from The Open Group (formerly X/Open), which maintains the Unix specification and trademark.
If you're working with Open Source code, this free library may be a useful reference for patching existing code for high-accuracy longterm time calculation.
Read the Solutions to the Year 2000 Problem by Steve Manley. Many of his suggestions can be applied to the 2038 problem, too.
Keep tabs on any recent updates on the 2038 Bug web site
(Source: the 2038 FAQ)
The End?
Before mass hysteria sets in, let's all remember that we have years, decades even, to deal with this latest programming glitch.
And as for the internet?
Well, I'm pretty sure that self-improving Artificial Intelligences will be running the world by then, so we probably don't need to worry too much about this.
Source: http://www.readwriteweb.com/archive...in_30_years.php
Have you heard the latest doomsday scenario? In thirty years, the internet will stop working! Apparently, a bug similar to the millennium bug will affect Unix-based systems, like those that run the tubes, in the year 2038. The bug, being dubbed the "2038 bug," arises because Unix-based systems store the time as a signed 32-bit integer, in seconds, from midnight on January 1 1970. And the latest time that can be represented in that format, by the Posix standard, is 3:14 AM on January 19, 2038. After that, times will wrap around and be represented as a negative number.
And then what happens?
Programs will fail, of course. Since they will see times not as being in 2038 but rather in 1901, erroneous calculations and decisions will occur. (It's true, I checked Wikipedia!)
We've actually seen fallout from the 2038 bug already, back in May of 2006 when the AOLserver web server software crashed. The software was designed so that database requests would "never" time out. Instead of assigning a "0" to the timeout, the software specified a timeout date one billion seconds in the future. One billion seconds (just over 31 years 251 days and 12 hours) after 21:27:28 on 12 May 2006 is beyond the 2038 cutoff date. The system calculated a timeout date that was actually in the past, got confused, and crashed.
The bug even affected the Mars Rover!
By 2038, it's likely that many of the susceptible machines will have been decommissioned before the critical date occurs. However, legacy systems and embedded systems could still be affected. These may include process control computers, space probe computers, embedded systems in traffic light controllers, navigation systems, routers, gas pumps, etc. It may not be possible to upgrade many of these systems, so they will need to be replaced.
I'm a Programmer - What Can I Do?
Test your code or use utilities such as the FakeTime Preload Library.
See the programming recommendations from The Open Group (formerly X/Open), which maintains the Unix specification and trademark.
If you're working with Open Source code, this free library may be a useful reference for patching existing code for high-accuracy longterm time calculation.
Read the Solutions to the Year 2000 Problem by Steve Manley. Many of his suggestions can be applied to the 2038 problem, too.
Keep tabs on any recent updates on the 2038 Bug web site
(Source: the 2038 FAQ)
The End?
Before mass hysteria sets in, let's all remember that we have years, decades even, to deal with this latest programming glitch.
And as for the internet?
Well, I'm pretty sure that self-improving Artificial Intelligences will be running the world by then, so we probably don't need to worry too much about this.Source: http://www.readwriteweb.com/archive...in_30_years.php
Have you heard the latest doomsday scenario? In thirty years, the internet will stop working! Apparently, a bug similar to the millennium bug will affect Unix-based systems, like those that run the tubes, in the year 2038. The bug, being dubbed the "2038 bug," arises because Unix-based systems store the time as a signed 32-bit integer, in seconds, from midnight on January 1 1970. And the latest time that can be represented in that format, by the Posix standard, is 3:14 AM on January 19, 2038. After that, times will wrap around and be represented as a negative number.
And then what happens?
Programs will fail, of course. Since they will see times not as being in 2038 but rather in 1901, erroneous calculations and decisions will occur. (It's true, I checked Wikipedia!)
We've actually seen fallout from the 2038 bug already, back in May of 2006 when the AOLserver web server software crashed. The software was designed so that database requests would "never" time out. Instead of assigning a "0" to the timeout, the software specified a timeout date one billion seconds in the future. One billion seconds (just over 31 years 251 days and 12 hours) after 21:27:28 on 12 May 2006 is beyond the 2038 cutoff date. The system calculated a timeout date that was actually in the past, got confused, and crashed.
The bug even affected the Mars Rover!
By 2038, it's likely that many of the susceptible machines will have been decommissioned before the critical date occurs. However, legacy systems and embedded systems could still be affected. These may include process control computers, space probe computers, embedded systems in traffic light controllers, navigation systems, routers, gas pumps, etc. It may not be possible to upgrade many of these systems, so they will need to be replaced.
I'm a Programmer - What Can I Do?
Test your code or use utilities such as the FakeTime Preload Library.
See the programming recommendations from The Open Group (formerly X/Open), which maintains the Unix specification and trademark.
If you're working with Open Source code, this free library may be a useful reference for patching existing code for high-accuracy longterm time calculation.
Read the Solutions to the Year 2000 Problem by Steve Manley. Many of his suggestions can be applied to the 2038 problem, too.
Keep tabs on any recent updates on the 2038 Bug web site
(Source: the 2038 FAQ)
The End?
Before mass hysteria sets in, let's all remember that we have years, decades even, to deal with this latest programming glitch.
And as for the internet?
Well, I'm pretty sure that self-improving Artificial Intelligences will be running the world by then, so we probably don't need to worry too much about this.
That's what I got from it basicly 
