Jump to content

On January 19, 2038, UNIX-based programs ....


wa1ex
 Share

Recommended Posts

Well I can certainly chime in on this from that website:

 

In my opinion, the Y2K38 threat is more likely to result in aircraft falling from the sky, glitches in life-support systems, and nuclear power plant meltdown than the Y2K threat

Aircraft will most certainly NOT fall from the sky. That is because flight control systems do not require nor use dates or time-of-day to safely stabilize and fly an aircraft. Automated aircraft navigators (Flight Management Systems) do use dates but only for display purposes, and generally NOT for providing flight path guidance to autopilots (when used in fully-coupled automated modes). So the absolute worst thing that could happen at "UNIX maximum time" on an airplane would be that its automated navigator MIGHT disengage, which would drop the autopilot into its basic flight control modes, which would cause the airplane to hold altitude and hold current heading... and further allow a pilot to command any new heading or any new altitude.Feel safe when flying...even through Y2K38! :D

 

RMT

 

 

Link to comment
Share on other sites

I do agree that the site feeds Fear, uncertainty and doubt. After all by 2038 we most certainly have 64-bit machines so 32-bit time_t will be a thing of the past (except for files encoded on the 32-bit file format).

 

What I worry about is the ATCT's will we need them by 2038? After all Air traffic has to be controllled by someone.

 

http://en.wikipedia.org/wiki/1996_Charkhi_Dadri_mid-air_collision

 

the 1996 Charkhi Dadri mid-air collision over India, partly resulted from the fact that the New Delhi-area airspace was shared by departures and arrivals, when in most cases departures and arrivals would use separate airspaces.

 

Again...this is unfounded fear as by 2038 most equipment and operating systems will probably be upgraded on 1st world countries.....

 

I guess we will have to wait for early warning signs til January 19, 2008, when 30-year mortgages will start to be calculated. :)

 

 

Link to comment
Share on other sites

My version of Ubuntu uses long int's for time_t which are 64 bit. (see /usr/include/bits/types.h)

 

A 64 bit machine has nothing to do with the definition of time_t. You can run 32 bit ubuntu and you are still safe from this bug, it's just a bit slower.

 

Storing seconds since the epoch in a 32 bit int is fine on a Linux system because you have the source code and you can recompile if need be.

 

Your totally hosed on other operating systems that have a tendency to deliver binaries and keep their source code hidden. You just have to pray that the guy who made your software, recompiles the code for you and hope that it doesn't cost a lot of $ to get the new version.

 

ANY application on ANY os can have the problem. It's not isolated to Unix or Linux. Unix/Linux makes it easier to fix because the definition for storing seconds since epoch is in a single place. And since Unix was where time_t was first used, the bug gets named after Unix. It should really be called the ISO time_t bug, NOT the unix 2038 bug. ISO set the standard for time_t. Blame them.

 

Coders can still use their own 32 bit int and store epoch seconds in it. It's not good form, and very uncommon when the code is reviewed by the public. But I've seen it, I've even done it some old apps I wrote on Windows. But that code isn't around today so it's no biggy. Using seconds since epoch is very common and unless you used 64 bit datatypes to store it, you're app is hosed. It's really no different than the y2k bug; it's gonna be hyped up, lots of people will make money from the hype, lots of people will get jobs to check for bugs, and.... NOTHING will happen.

 

People in the Open Source camp don't have to worry about anything. Binary folks sure do.

 

I've never flown. Maybe one day when all the hardware/software in the vehicle is open source I'll try it.

 

http://rss.slashdot.org/~r/Slashdot/slashdot/~3/202963032/article.pl

 

Grats Mop on fixing the URL bug. ;-)

 

 

Link to comment
Share on other sites

  • 2 weeks later...

Well, most people talk about financial date bugs occuring with software, but recently I found out that computer are not all the great with math as a whole. Take sin and cos values and floating point values - computers have to have programs that compensate for such calculations because the math theory and proven math that came out for that type of math really can not be done with computers. There are inherent miscalculations by trying to use a computer for such computations. It is well known that you only get an approximation in science programs using a computer. Exstensive revisions to computer code has to be done to science programs to become accurate than the programs given with the math nowadays done in computer programs. Computers are not accurate when calculating those type of values. Computers are close but not really close enough for true accurate math of some functions used in science and math programs or what is really needed by a scientist or mathematican.

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...