Comment 8 for bug 779908

FWIW: Trying to debug the problem myself, I built pdftk from the package myself (`apt-get source pdftk`, `make -f Makefile.Debian`).
The resulting stack trace was a little more helpful:
$ ./pdftk base14-fonts.pdf output a.pdf verbose
Command Line Data is valid.

Input PDF Filenames & Passwords in Order
( <filename>[, <password>] )
   base14-fonts.pdf

The operation to be performed:
   filter - Apply 'filters' to a single, input PDF based on output args.
      (When the operation is omitted, this is the default.)

The output file will be named:
   a.pdf

Output PDF encryption settings:
   Output PDF will not be encrypted.

No compression or uncompression being performed on output.

Creating Output ...
Unhandled Java Exception:
java.lang.ArrayIndexOutOfBoundsException: 4
   at java.text.SimpleDateFormat.formatWithAttribute(SimpleDateFormat.java:793)
   at java.text.SimpleDateFormat.format(SimpleDateFormat.java:845)
   at java.text.DateFormat.format(DateFormat.java:419)
   at com.lowagie.text.Document.addCreationDate(pdftk)
   at com.lowagie.text.pdf.PdfDocument.<init>(pdftk)
   at com.lowagie.text.pdf.PdfStamperImp.<init>(pdftk)

Ultimately, I tracked the problem down to java/com/lowagie/text/Document.java l.644 - the addCreationDate() function. There, a new SimpleDateFormat object is created, with the format string "EEE MMM dd HH:mm:ss zzz yyyy" and no locale. When subsequently its format method is applied to "new Date()" (which is valid), said exception occurs. If the "MMM" part is removed, everything succeeds as it should. I also tried explicitly specifying the en_US locale, but to no avail (I'm using de_AT myself).