Are you certain you had both the quilt patch applied and HAVE_SYSTEM_TZDATA undefined? What did you pass in for '--with-system-tzdata' to configure? Or did you unset HAVE_SYSTEM_TZDATA in some other way?
I double-checked the state of the patched ext/date/lib/parse_tz.c in 5.3.9-5, and it appeared the same as in my original pastebin: the preprocessor directives are still in the same place. So, I don't understand how it could possibly work for you: it seems to produce invalid C from the preprocessor stage.
To show that, here's another pastebin, this time the result of running gcc -E ext/date/lib/parse_tz.c, which should just do the preprocessing: http://paste.debian.net/154235/ - note the hanging else clause.
What is your build environment?
# uname -a
Linux dominic-vm-lucid 2.6.32-36-server #79-Ubuntu SMP Tue Nov 8 22:44:38 UTC 2011 x86_64 GNU/Linux
# gcc -v
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
What else would you like to know? I'm pretty sure this is unrelated to my environment. To be clear: I'm not saying it happens with a normal build (because most people building the package will want to use system TZ data), but it's still a bug that affects the few people (I assume) who don't.
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org