Support PDF 2.0 dates and tighten date validation

[thomasbuilds]

closes #629

[thomasbuilds]

I noticed a couple of preexisting issues in parseDate. They may be worth handling in a separate PR, since this PR is mainly about accepting the PDF 2.0 date syntax, but they’re relevant to the rewritten parser.

1. UTC offset handling is semantically inverted.

The current arithmetic, preserved from main, does:

case "-":
    hours -= offsetHours;
    minutes -= offsetMinutes;
    break;
case "+":
    hours += offsetHours;
    minutes += offsetMinutes;
    break;

Per ISO 32000-2 §7.9.4, an offset of -08'00 means the local time is 8 hours earlier than UTC, so normalizing to UTC should add 8 hours, not subtract. pdf.js handles it the other way:

https://github.com/mozilla/pdf.js/blob/v5.6.205/src/display/display_utils.js#L551-L561

However, just flipping the signs would not fully fix it, because Calendar.getInstance() uses the device timezone. If we normalize fields to UTC and then set them on a default-timezone Calendar, the resulting instant is still wrong. A complete fix would probably need to build the calendar in UTC, then format the resulting Date in the default timezone, for example

final Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
// set fields and apply offset to normalize to UTC
return DateFormat.getDateTimeInstance(...).format(calendar.getTime());

2. Calendar leniency accepts impossible dates.

D:20230231 is currently accepted and silently rolls over to March 3. If we want strict validation, we’d need something like

calendar.setLenient(false);
calendar.getTime();