Bug 59780

Summary: SimpleDateFormat usage incorrect in PackagePropertiesPart class
Product: POI Reporter: Eliut Hernandez <eliut.hernandez>
Component: POI OverallAssignee: POI Developers List <dev>
Severity: critical    
Priority: P2    
Version: 3.14-FINAL   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: J-Unit Test for PackagePropertiesPart.setDate Method

Description Eliut Hernandez 2016-07-01 16:56:33 UTC
Created attachment 34000 [details]
J-Unit Test for PackagePropertiesPart.setDate Method

We're facing an issue with the PackageProperties.setDateValue(String) method while parsing a XLSX file containing a creation Date/Time of 


Upon inspection, there are quite a few issues with the formats used for attempting to parse this ISO-8601 value.

This declaration

    DEFAULT_DATEFORMAT =  "yyyy-MM-dd'T'HH:mm:ss'Z'";

is declaring Time Zone format code of Z as a literal String instead of just using Z.

The second declaration 

    ALTERNATIVE_DATEFORMAT ="yyyy-MM-dd'T'HH:mm:ss.SS'Z'";

has the same issue as the first, with the additional problem that the Milliseconds values should be captured via "SSS" and not "SS".

Lastly, format Z only works with Time Zone offsets that do not contain ":" characters in them, such as +0300 (vs +03:00). As of JDK 1.7, SimpleDateFormat added code X to handle both.

Attached is a J-Unit test re-affirming the above along with a fix we're going to be looking at applying locally until this is fixed.
Comment 1 Nick Burch 2016-07-04 20:56:09 UTC
We still support Java 6, so we can't sadly use the nice X type

We already have some timezone support, in r1751379 I've expanded it slightly and added some read and write unit tests

Could you please grab a svn build / nightly build / wait for 3.15 beta 3, and let us know if that solves it? (It's a slightly different route to what you've done in your junit)
Comment 2 Eliut Hernandez 2016-07-05 14:17:46 UTC
Thank you for the prompt response.

We will try out the patch immediately.
Comment 3 Eliut Hernandez 2016-07-11 13:45:00 UTC
This worked just fine for us, thank you.