Uhhhhh ... didn't Congress just change how DST is handled starting in 2007, thus requiring updates to any computer (or VCR or DVD Recorder or anything else) which automatically handles DST? Arbitrary actions by Congress is not something designers can plan ahead for.
This isn't really so much of an issue. Most computers for which such things are really important use UTC (formerly GMT) as their reference point for time. There is no "daylight savings" or other silliness in UTC time, thank goodness.
Unix-based computers, for instance, generally have clocks that run UTC. When you ask the computer what time it is, it checks for an environment variable called, appropriately enough, "TZ", then it calculates what it should be displayed based on the value of this variable. If this variable is unset, it checks a file called in the /etc directory called "timezone" and applies the calculation to that. If that file doesn't exist, it displays UTC/GMT time. This time is based on the number of seconds that have elapsed since Jan. 1, 1970. Leap seconds cause problems with this system because the conversion from the number of seconds since 1/1/1970 is actually greater than it was initially expected to be, thus in an absolute sense generating the precise date from the number of elapsed seconds gives an incorrect answer.
In a practical sense, this is generally worked around a number of different ways. I recently read a really interesting white paper about discussions that have occured at various IEEE and IETF sessions on the matter. One solution might be to include a lookup table that contains the dates that these leap seconds are added so the conversions would be more accurate. It actually all gets very cloudy inside the workings of how these conversions could or should be done, but it is an interesting problem IMO, as I've always been pretty interested in timekeeping, and the history of it.
We'll, that's probably more than you ever cared about reading about this stuff, so I'll stop now.:-)