That pretty strongly implies that all known strange-behavior is not a bug. Also, all known bugs are not bugs, as they can be known and worked around.
If you had to shut down your computer during the year cross-over, would you consider it a bug? Or what if you couldn't go on your business trip because of the year cross-over.
And a bug in the spec is still a bug. Oversights in specifications are equivalent to oversights in programming.
If I commissioned a computer to be made that wasn't supposed to be able to span the new year then no I would not consider it a bug that it could not span the new year. Sure it would be great if it would do that (though only if I had asked that it would), but as long as it behaves exactly as expected then I'm happy. No astronauts die and my budget won't cut. Success.
A similar parallel in consumer computing is switchable graphics. The first models that supported this required a reboot to accomplish it. That wasn't a bug, just part of the plan. They have since gotten more advanced and allow switching without a restart.
Which is why I specifically included the business trip part. They had to schedule around those dates, losing a week or more of possible launch times, because they couldn't handle a year+1 operation. Given how picky they are with launch windows, this could easily mean large delays, meaning large amounts of money.
I don't know why planning a launch several years in advance a week later means a huge cost. They never scheduled a flight and had to change it because of the limitation, it was built into the calendar. Not having shuttles in the air during New Years might actually save money--less overtime pay.
The difference is that NASA uses systems engineers. From their point of view, it is not the "program" which can have bugs, but rather the "system" in its entirety—where "system" consists of the software, the hardware in the field, the hardware in the control center, and all the operations staff paid to perform certain tasks (i.e. execute algorithms—basically additional hardware.) If one part of your system (the software) needs to be rebooted, but another part (the people) is "programmed" to do it autonomously, then the system as a whole has no bugs.
It's sort of the thinking that goes into Erlang programs—rather than, say, thinking out complex GC strategies, you just create little process-sized vessels which grow, overflow, are killed, and then are recreated by other processes. It's not a "bug" that an individual process has died any more than it's a bug when one of the cells in your body dies.
