Not only that, the problem was date/time related. Dates and times seem to be one of the most tricky things to account for and are consistently taken for granted, introducing unexpected errors. You would think by now someone would have made a fortune developing a robust radiation tolerant datetime IC, that has enough bits to count milliseconds from the big bang until the estimated end of the universe.

As Peter van der Linden says in his (excellent) book Expert C Programming: "Anyone who thinks programming dates is easy to get right the first time probably hasn't done much of it."

What's so special about that date? I guess in whatever datetime representation they were using, it overflowed at that point?

It seems to be approximately 2^32 tenths of second into the new millennium. Which is an odd way to do things, but I guess there were reasons.

Seems so

  h> logBase 2 . realToFrac $ (secs "2013-08-11" - secs "2000-01-01")*10
  31.999992174768167

Totally off-topic, but that looks a lot like Haskell, what did you do to make ghci have such handy calculator functionality? (I can't find secs in Hoogle)

It's just

  secs = utcTimeToPOSIXSeconds . readTime defaultTimeLocale "%F"

The standard for astronomical measurements today is the J2000.0 epoch.

http://en.wikipedia.org/wiki/Epoch_%28astronomy%29#Julian_ye...

I bet there's a:

    \\TODO: reset the clock before launch day

Somewhere that would have allowed it a ~13 years lifetime from launch day on instead of from 2000 on..

I bet that during the initial design phase, they wanted to keep the design simple, have enough timekeeping range to cover the mission and then maximize temporal resolution.

Someone realized that a counter operating on tenths of a second from 2000 was both easy to use and sufficient for the primary mission... they then thought nothing of it until the loss of contact