Hi, On Thu, Apr 29, 2010 at 4:07 PM, Johannes Koch <[email protected]> wrote: > I had a short look at the DateConverter because the trunc currently does not > build because of test failures/errors. > > To me it looks like the date format issues are related to > a) the locale, and > b) the time zone. > > a) The array POTENTIAL_FORMATS in DateConvertor is initialized with a number > of SimpleDateFormats that use the default locale, which may not be > Locale.ENGLISH, and so will not necessarily parse "Tuesday".
I guess the locale of the formats should be explicitly set to ENGLISH, as AFAIUI pretty much all the non-numeric date information in PDFs is in English. > b) While TestDateUtils.testDateConverter() sets the time zone to UTC, this > does not affect the previously created SimpleDateFormats for > DateConvertor.POTENTIAL_FORMATS, which were created using the default time > zone. The reason why I forced the time zone to UTC in the test case is to make the string output of DateConverter.toISO8601 predictable for use in the assertions. We could probably work around that by making the test case more intelligent. I'm not sure whether it's a good idea to assume a specific time zone (like UTC) for PDF date formats that don't have explicit time zone data, or if we should keep using the default time zone like we now do. The former approach would make the interpretation of PDF documents more deterministic, but the latter is probably better in line with what normal users expect. BR, Jukka Zitting
