PDA

View Full Version : Y2K-like fears create shuttle scheduling crunch



01101001
2006-Nov-07, 02:54 AM
NewScientist: Y2K-like fears create shuttle scheduling crunch (http://www.newscientistspace.com/article.ns?id=dn10459)


NASA hopes to get its next space shuttle off the launch pad and back on the ground by the end of 2006 in order to avoid the spectre of problems once ascribed to 'Y2K'. It is now considering moving the shuttle Discovery's planned lift-off ahead by one day, to 6 December.
The space shuttle's computer software is about 30 years old and does not recognise when the calendar year switches. On 1 January 2007, for example, it will think it is day 366 of 2006 a problem NASA calls 'year-end rollover'.
To reset the time, the shuttle's main computers would have to be 'reinitialised', which would mean a period without navigation updates or vehicle control, a situation NASA obviously wants to avoid.

Nowhere Man
2006-Nov-07, 03:37 AM
Speaking as a programmer... :wall:

Fred

Nicolas
2006-Nov-07, 08:26 AM
They *could* reasonably safely reset the things while attached to the ISS I think.

Maksutov
2006-Nov-07, 09:15 AM
One wonders about how much money was saved by having the year represented by two digits versus how much money was spent fixing or preventing the problems that such a shortcut created.

IBM 1979:


Software Manager: You know, we could get this out to the market a lot quicker and cheaper if we devote just enough code to support two digits for the year. After all, 2000 is 21 years away. I'm sure by then this won't be causing any problems.

Executive Suit: Do it! (and I'll get a nice bonus for such a cost-cutting move!).

Nicolas
2006-Nov-07, 12:41 PM
15 years later:



Programmer: Hey, maybe we should change that old, always re-used time module, as 2000 is not so far away anymore

Executive Suit: Did you just use the C-word?? OUT! OOOUUUT! Anarchist!

Larry Jacks
2006-Nov-07, 01:39 PM
One wonders about how much money was saved by having the year represented by two digits versus how much money was spent fixing or preventing the problems that such a shortcut created.

Using two digits to represent a year value goes way back, probably to the 1960s when large scale business applications and databases were created. At that time, memory (RAM) and storage were very expensive. Cutting two bytes off of every date record saved them tons of money. By the time it became a problem, memory and storage cost were practically nothing by comparison. It did force many companies to upgrade or replace their old legacy code systems. Many companies found that the efficiencies of replacing the entire system more than offset the cost.

ToSeek
2006-Nov-07, 03:36 PM
Most spacecraft I've dealt with keep time based on the number of seconds or days since an epoch date, not calendar time. I'm a little surprised the shuttle doesn't do the same.

Jason Thompson
2006-Nov-08, 03:06 PM
Question: will the shuttle computer actually care if it thinks it is day 366 of 2006? Has it been told that there are 365 days to a year and will therefore go haywire when it gets confused by seeing the impossibility of a 366th day in a non-leap year? Or will it merrily carry on doing what it is told?

This is what I don't get about the 'Y2K' style issues. Does a computer really care if it uses 00 to represent the year? Does a computer's ability to do anything actually depend on that? My computer has a calendar and a clock on it, but I can set those myself because it has to operate in different time zones in order to be a marketable product. Don't most computer controlled devices like shuttle computers depend on a person telling it to start something at a given time and then doing everything based on elapsed time since the start of the program?

Does anyone have any examples of a situation where a computer incorrectly representing the date according to a Western calendar is actually a problem?

Larry Jacks
2006-Nov-08, 04:58 PM
The biggest concern during Y2K related issues dealt with programs that used dates for calculations (e.g. computing interest), sorting (e.g. billing records), etc. Those types of applications could be easily upset by having the year value go from 99 to 00. That's why they had to be fixed. At the same time, a lot of the Y2K hysteria was simply hype with no basis in reality.

Not having access to the Shuttle flight software, I have no idea how they're using dates internally. Perhaps it's being used in the orbit propagators. If that's the case, then it was poorly defined, IMO. However, changing Shuttle software is an expensive proposition and may not be worth it if the Shuttle is going to be retired in a few years. If it affected flight safety in a serious manner, then yes, change it. However, if all it casues is an occassional scheduling inconvience, why bother?

Laguna
2006-Nov-08, 07:58 PM
Does anyone have any examples of a situation where a computer incorrectly representing the date according to a Western calendar is actually a problem?
Think of this scenario. You buy something on 29th of December.
The computer of the store prints the bill, that will be shipped to you, on January 2nd. If now the year on that computer turned back 20 years, then the marshal? might be earlier at your door than the bill.

loglo
2006-Nov-08, 10:19 PM
One wonders about how much money was saved by having the year represented by two digits versus how much money was spent fixing or preventing the problems that such a shortcut created.

IBM 1979:

I think you will find that the date "cutting" was largely driven by the high cost of storage. I started in IT around then and it was very expensive to buy a hard disk array. I recall the company saved over a million dollars by buying non-IBM disks. This would be for about the amount of storage contained on a single PC hard drive nowadays.

Jason Thompson
2006-Nov-09, 03:50 PM
Think of this scenario. You buy something on 29th of December.
The computer of the store prints the bill, that will be shipped to you, on January 2nd. If now the year on that computer turned back 20 years, then the marshal? might be earlier at your door than the bill.

Why would it turn back 20 years? That's not a scenario ever proposed. But even so where's the problem? If a bill turns up dated twenty years too early then its obviously a simple error. It hasn't caused me much more than a laugh. There will be all sorts of other information on the bill (my address,. card numbers, and so on) that will show the date to be in error.

This is my point. If the purchase date is 29/12/99 and the bill date is 02/01/00 what's the problem?

tofu
2006-Nov-09, 08:33 PM
Does anyone have any examples of a situation where a computer incorrectly representing the date according to a Western calendar is actually a problem?


I had a problem a couple of weeks ago where something I wrote was making hourly log entries in a database, and I had set up the database table to use a datetime field as the primary key. The clock on the server automatically stepped back one hour for daylight savings time, and I started getting primary key constraint violations. So, lots of bad design there - but it all seemed ok to me at the time I wrote it.


The quintessential Y2K example is where you have a report or something that ends up displaying dates after 1999 like this: 01 / 01 / 100. I have seen examples of that happening, though I can't remember specifics. A date printout going from 1999 to 19100 like that is a cosmetic problem, but not a civilization ending event like some people thought it would be. And if you're talking about a clock in a computer, this was the most likely problem. It is far more likely that an internal clock would tick from 99 to 100, than from 99 to 00 (which would cause problems) because no variable type is going to wrap at 99. 127 maybe, or more likely 255, but not 99.

The real issue, I think, would have been situations were a user had to enter a date and was only given two digits of space in which to enter it. So like for example, "input the date that this bill is paid:" and the user inputs 1/1/00. The program looks up the date that the last bill was paid (in '99) and decides that, "you can't pay a bill on 1/1/00 because you've already paid a later bill."

Or alternately, the computer's internal clock was correct and knew it was 2000, but the two-digit data entry recorded "00" as 1900. So even though you keep paying your mortgage, the computer thinks that your last payment was in 1999 - all the other payments were dated 1900. So now you're way behind and it starts added penalties.

pghnative
2006-Nov-09, 09:04 PM
Think of this scenario. You buy something on 29th of December.
The computer of the store prints the bill, that will be shipped to you, on January 2nd. If now the year on that computer turned back 20 years, then the marshal? might be earlier at your door than the bill.

Why would it turn back 20 years? Edited to add: I can think of scenarios where it would turn back 20, but it is easier to imagine turning back 100. So from Dec 31 1999 to Jan 1, 1900 in one day, because the computer treats 01-01-00 as Jan 1 1900.


That's not a scenario ever proposed. But even so where's the problem? If a bill turns up dated twenty years too early then its obviously a simple error. It hasn't caused me much more than a laugh. There will be all sorts of other information on the bill (my address,. card numbers, and so on) that will show the date to be in error.

This is my point. If the purchase date is 29/12/99 and the bill date is 02/01/00 what's the problem?A better example would be if your bill date was Dec 29, 1999, and you didn't pay it until Feb 3rd 2000. When the computer tried to calculate how much interest you owe, it might read your payment as arriving early, and wouldn't charge you at all.

Not a problem for you, but certainly a problem for the company expecting to collect interest.

So if a computer makes a decision based on the date, then clearly it will make the wrong decision when the year rolls over. How bad that decision is, and to what extent a human could override that decision, depends on how the software is designed. None of us know that.

NEOWatcher
2006-Nov-10, 01:31 PM
One additional problem is delta computation.
Years ago at my last job, when connect time was expensive, we would charge our branch offices for connect time. We had to be very careful not to have anyone online when we set the clock back in the fall. Since the computation was un-signed subtraction, a negative was just an integer rollover, and we would end up charging that poor person billions.
Imagine if some control system was basing it's function the same way. "FULL THRUST".

At the company I work now, dates in our legacy systems are stored 2 byte with thousands representing number of years past 1970 and the remainder the days of the year (just in case we have 600 leap days in a year).
The cost of converting old data was cost-prohibitive, so we still have the same 2 byte date concept, except now we are in negative years, and the formulas just know that.

novaderrik
2006-Nov-12, 06:32 AM
i thought all the shuttle systems have gotten overhauled and replaced a few times over the past couple of decades.

Sticks
2006-Nov-12, 07:20 AM
I remember reading the story of how some programmers had got a system into 4 date figures, only to be ordered to set it back to the 2 figure date figure, because 4 figures were not in the official standard. / quality system :wall:

NEOWatcher
2006-Nov-13, 01:57 PM
I remember reading the story of how some programmers had got a system into 4 date figures, only to be ordered to set it back to the 2 figure date figure, because 4 figures were not in the official standard. / quality system :wall:
The wonderful world of business. Just last week, I was told, "yes, that's the right way, but I don't think we can convince the auditors"