Real-time clock reset breaks boot-time fsck?

I just had some trouble recovering from a failure in Lucid to handle an empty laptop battery; see bugs 555585, 555665. The salient part is that I rebooted with my real-time clock reset to some time in the distant past.

Instead of recovering from this, the boot-time fsck failed and threw the boot procedure into the new "fsck failed, what now?" menu. I'm not sure what the right way to handle this situation would be, but one wonders if either fsck could ignore "timestamp" problems if it's obvious that the clock is wrong (e.g. because it's older than the fsck binary) or the boot-time fsck run could somehow force fsck to "fix" the problem.