You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Johannes Koch <jo...@fit.fraunhofer.de> on 2010/04/29 16:07:16 UTC
Date format issues
Hi,
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".
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.
--
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
Re: Date format issues
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Johannes Koch schrieb:
> Hi
>
> So we could keep the default time zone in DateConvertor. Then, in the
> tests, change the converted date to UTC timezone for comparison.
+1
Thank you for handling that issue. I'm sorry that I didn't run the test after
applying the patch which triggers the regression.
BR
Andreas Lehmkühler
Re: Date format issues
Posted by Johannes Koch <jo...@fit.fraunhofer.de>.
Hi
Jukka Zitting schrieb:
> Hi,
>
> On Thu, Apr 29, 2010 at 4:07 PM, Johannes Koch
> <jo...@fit.fraunhofer.de> 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
Re: Date format issues
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Apr 29, 2010 at 4:07 PM, Johannes Koch
<jo...@fit.fraunhofer.de> 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