Hi
Jukka Zitting schrieb:
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.
ACK
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.
So we could keep the default time zone in DateConvertor. Then, in the
tests, change the converted date to UTC timezone for comparison.
--
Johannes Koch
Fraunhofer Institute for Applied Information Technology FIT
Web Compliance Center
Schloss Birlinghoven, D-53757 Sankt Augustin, Germany
Phone: +49-2241-142628 Fax: +49-2241-142065
