allthingssecurity opened a new pull request, #27106: URL: https://github.com/apache/camel/pull/27106
# Description [CAMEL-25151](https://issues.apache.org/jira/browse/CAMEL-25151) `DateFormatFactory` (used for every `java.util.Date` field of a CSV, fixed-length or key-value pair model) refuses any value that has more characters than its pattern, with `FormatException: Date provided does not fit the pattern defined`. A pattern letter count is a minimum width, not a maximum, so valid dates in the pattern's own format are rejected: | pattern | value | today | |---|---|---| | `M/d/yyyy` | `12/25/2026` | FormatException (10 characters for an 8 character pattern) | | `d.M.yyyy` | `25.12.2026` | FormatException | | `MMMM d yyyy` | `September 30 2026` | FormatException | | `h:mm a` | `11:45 PM`, and also `9:05 AM` | FormatException for every value | Bindy cannot read back what it writes: marshal of 2026-11-30 with `M/d/yyyy` gives `11/30/2026`, and unmarshal of that text fails. For `M/d/yyyy` about four dates out of five fail (every day from the 10th, and every date from October to December). The check exists to reject a date followed by other characters, such as `20090901-10:32:30` for `yyyyMMdd`, because `DateFormat.parse(String)` stops at the end of the pattern and ignores the rest. CAMEL-11620 removed the same check from the `LocalDate`, `LocalDateTime` and `LocalTime` factories (the pull request for it only touched those three), but not from the `java.util.Date` one. This change keeps the check for what it was meant to catch: a value longer than the pattern is parsed with a `ParsePosition` and accepted only when the whole value was used; if it cannot be parsed, or characters are left over, the same `FormatException` with the same message is thrown as before. A value that is not longer than the pattern takes exactly the same code path as today, so every value that is accepted today is accepted with the same result, and every error that is raised today for such a value is unchanged. The only behaviour change is that a value longer than its pattern that is entirely a date in that pattern is now accepted. With `SimpleDateFormat` rules that also includes, for example, `001/01/2026` for `dd/MM/yyyy` (read as 1 January), which is the same thing `SimpleDateFormat` already does for shorter values such as `1/01/02026`. Tests: - New `BindyCsvDatePatternValueLongerThanPatternTest`: unmarshal of the four values above; marshal/unmarshal round trip of four dates with those patterns; a control that `12/25/2026-01` (a date followed by other characters) and `13/45/2026` (not a date) are still rejected with the same `FormatException` and message. - Without the change: the unmarshal and round-trip tests fail with `Date provided does not fit the pattern defined, position: 1, line: 1`, the control passes. The existing `BindySimpleCsvUnmarshallTest.testMessageWithErroneousDate` and `BindySimpleCsvUnmarshallPositionModifiedTest` (a date followed by other characters) pass unchanged. - With the change, the whole camel-bindy module: 231 tests, 0 failures, 0 errors, 3 skipped. Found with a Lean 4 model of the length check (for patterns of numeric fields and literals it accepts the output of `format` exactly when no value has more digits than its pattern letters), then reproduced with the real classes on main. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested the affected module, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 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]
