pjfanning opened a new pull request, #1270: URL: https://github.com/apache/poi/pull/1270
Fixes https://bz.apache.org/bugzilla/show_bug.cgi?id=70229 `PackagePropertiesPart.parseDateValue` used `SimpleDateFormat` patterns to parse `dcterms:created` / `dcterms:modified`. The `yyyy-MM-dd'T'HH:mm:ss.SS'Z'` pattern accepts any number of fractional digits and treats the whole run as a millisecond count, so `2026-01-01T00:00:00.999999999Z` was parsed as `2026-01-12T13:46:39.999Z` (999999999 ms ≈ 11.57 days added). ### Change - Replace the `SimpleDateFormat` pattern list (and the `TIME_ZONE_PAT` colon-stripping regex) with a single `java.time.DateTimeFormatter` built for the W3CDTF profile: `YYYY[-MM[-DD[Thh:mm[:ss[.s+]][TZD]]]]`. - 1–9 fractional-second digits are accepted and truncated to millis when converted to `java.util.Date`. - TZD may be `Z`, `±hh:mm`, or (leniently, as before) `±hhmm`; a missing offset is treated as UTC, as before. - `YYYY`, `YYYY-MM` and `hh:mm`-without-seconds forms — valid W3CDTF that the old code rejected — now parse, defaulting missing fields to the start of the period. - Date formatting on write also moves to `DateTimeFormatter`; output is unchanged (`yyyy-MM-dd'T'HH:mm:ss'Z'`). - Tests added to `TestPackageCoreProperties.testSetProperties` for long fractions, short fractions, the extra W3CDTF forms, and a few malformed inputs. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
