Corrupted (?) commit 6e6db85e confusing gitk

When I run

    gitk 6e6db85ea9423eea755cf5acf7a563c0d9559063

gitk complaints with 'Error: expected integer but got "Hamano"'.

I tracked the problem down to the raw content of the commit object. The author line is lacking time and timezone information:

     $ git-cat-file -p 6e6db85ea9423eea755cf5acf7a563c0d9559063
     tree 5265f13d094e7c453a06f097add25eaefb843a79
     parent d25430c5f88c7e7b4ce24c1b08e409f4345c4eb9
     author Junio C Hamano <gitster@pobox.com>
     committer Junio C Hamano <gitster@pobox.com> 1196466497 -0800

     Run the specified perl in Documentation/

     Makefile uses $(PERL_PATH) but Documentation/Makefile uses "perl";
     that means the two Makefiles actually use two different
     Perl installations.

     Teach Documentation/Makefile to use PERL_PATH that is exported  
from the
     toplevel Makefile, and give a sane fallback for people who run  
"make"
     from Documentation directory.

     Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitk fails to parse this because it expects the time to be the second item from the end of a line (look for "set audate" in function parsecommit of gitk). For the commit above, gitk finds "Hamano" instead of the correct time.

I'm pretty convinced that the original commit is reported correctly. I verified that with two different versions of git (1.5.3.7.949.g2221a6 on mac and 1.5.3.6.1889.g98603 on mingw). Both report the raw commit without time and timezone.

I'd like to conclude with some questions:
  - Is this commit corrupted?
  - How was the commit created?
  - Should "git fsck" detect such corruption?
  - Should gitk more gracefully handle corrupted commits?

I do not have solutions yet.

	Steffen