|Summary:||SimpleDateFormat usage incorrect in PackagePropertiesPart class|
|Product:||POI||Reporter:||Eliut Hernandez <eliut.hernandez>|
|Component:||POI Overall||Assignee:||POI Developers List <dev>|
|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 "2016-06-28T16:26:46+03:00" 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.