SA Explorer 8000SD/HD Experiences Y2K-like Bug

An anonymous reader writes "According to an article at Audioholics, a firmware bug was just discovered in the Scientific Atlanta 8000SD and 8000HD DVRs (Digital Video Recorders) which renders them unable to record. This firmware bug was discovered when the units attempted to recognize February 29th on the programming guide. The units are apparently unable to recognize this date, and as a result, shut down all record functions. All other aspects of the 8000 will continue to work. So far, it looks like no previously recorded material was lost. Scientific Atlanta is apparently in "Emergency Session" working on a software patch. The problem began occuring on the 23rd when the 7-day program guide first began to encounter the February 29th programming."

Comments

Graceful Error Handling?

[angst_ridden_hipster]

To quote a widely-used software development guideline document*:

"Well-written applications include error-handling code that allows them to recover gracefully from unexpected errors. When an error occurs, the application may need to request user intervention, or it may be able to recover on its own. In extreme cases, the application may log the user off or shut down the system."

Now, I figure encountering a nonexistent date may well qualify as an "extreme case." Still, a developer might want to at least think a bit about calendars before qualifying February 29th as nonexistent.

(* It's from a Microsoft Developer Guideline. I put that as a note, since if I started with it, I'd be suspected of troling).

Re:getting the splinter and missing the 2x4?

[spitzak]

Actually the weird thing about getting 2000 wrong (it *IS* a leap year) is that it requires more research to actually get it wrong. A very simple approach would get it right.

In order of complexity leap year algorithims are:

0. No year is a leap year (2000 is wrong)
1. All years where n%4==0 are leap years (2000 is right)
2. Except when n%100==0 (2000 is wrong)
3. Except when n%400==0 (2000 is right)

For some reason a huge number of people are at aware of the rules up through #2 above, even though knowing only #1 would make the results more correct.

Off-topic anecdote

[notsoclever]

Once upon a time (1997 or so) I worked in my university's data center, performing reporting queries for various departments. One of these queries was for determining who should get a mailing for a scholarship, which required that the students graduated high school after May 1996.

So, I did something like

SELECT * FROM student_table WHERE hs_grad_date > '05/01/1996';

and it spat out a whole bunch of rows, and I was about to send off the results as "complete," until suddenly I noticed quite a few entries for people who has graduated from the university in the 1970s.

So I looked more closely at the various columns, and noticed that quite a few of them had a graduation date of 09/09/1999 and that the field indicating that they had gotten a GED instead of graduating normally was filled.

Apparently, back then the database server they had didn't allow a field to remain blank (since it was all legacy which had been migrated between at least a half a dozen architectures by the time I'd had any part in it), so of course if there was no information available they just put in 9/9/99.

I bet that when the report was run in 2000, a lot of students who had already gotten their degrees decades before were quite surprised to get a mailing informing them that they had qualified for the scholarship!