[jira] [Resolved] (CAMEL-25151) camel-bindy - a java.util.Date field rejects a valid value that is longer than its pattern (M/d/yyyy with 12/25/2026, h:mm a, MMMM), so Bindy cannot read back dates it has written

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-25151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-25151.
---------------------------------
    Fix Version/s: 4.23.0
       Resolution: Fixed

The fix is merged on main, so it is in Camel 4.23.0:
* aeaf7d9db100 CAMEL-25151: camel-bindy - a java.util.Date value longer than its pattern is parsed

Resolving, as the ticket was not updated when the PR was merged.

_Claude Code on behalf of Claus Ibsen_

> camel-bindy - a java.util.Date field rejects a valid value that is longer than its pattern (M/d/yyyy with 12/25/2026, h:mm a, MMMM), so Bindy cannot read back dates it has written
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25151
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25151
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-bindy
>            Reporter: shashank
>            Priority: Minor
>             Fix For: 4.23.0
>
>
> {{DateFormatFactory.DatePatternFormat.parse}} (used for every {{java.util.Date}} field of a CSV, fixed-length or key-value pair model) refuses a value that has more characters than the pattern:
> {code:java}
> if (string.length() <= this.pattern.length()) {
>     df.setLenient(false);
>     return df.parse(string);
> } else {
>     throw new FormatException("Date provided does not fit the pattern defined");
> }
> {code}
> A pattern letter count is a minimum width, not a maximum: {{M}}, {{d}}, {{H}} and {{h}} print two digits for values of 10 and more, {{MMMM}} and {{EEEE}} print full names, {{a}} prints {{AM}}/{{PM}} for one letter. So valid dates in the pattern's own format are rejected:
> ||pattern||value||result||
> |{{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}}, also {{9:05 AM}}|FormatException for every value|
> |{{dd-MM-yyyy}}|{{25-12-2026}}|ok (the width is fixed)|
> This also breaks the round trip: marshal writes {{12/25/2026}} for the pattern {{M/d/yyyy}}, and unmarshal of that text fails with "Date provided does not fit the pattern defined". For {{M/d/yyyy}} about four dates out of five fail (every day from the 10th and every date in October to December).
> The check was added 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, but not from the {{java.util.Date}} one.
> h3. Reproduction
> {code:java}
> @CsvRecord(separator = ";")
> public static class Row {
>     @DataField(pos = 1, pattern = "M/d/yyyy")
>     private Date us;
> }
> // unmarshal of "12/25/2026" -> IllegalArgumentException: Date provided does not fit the pattern defined, position: 1, line: 1
> // marshal of 2026-11-30 gives "11/30/2026", and unmarshal of that text fails the same way
> {code}
> A unit test with the four patterns above fails on main. A small formal model (Lean 4) of the check shows that it accepts the output of {{format}} exactly when every numeric field has no more digits than its pattern letters, and that the fix below accepts every formatted date and still rejects a date followed by other characters.
> h3. Affected versions
> The check is the same in 2.25.0, 3.0.0, 4.0.0, 4.14.0, 4.18.0, 4.22.0 and main.
> h3. Proposed fix
> Keep the check for what it was meant to catch: when the value is longer than the pattern, parse it with a {{ParsePosition}} and accept it only when the whole value was used; otherwise throw the same {{FormatException}} as before:
> {code:java}
> } else {
>     df.setLenient(false);
>     ParsePosition position = new ParsePosition(0);
>     date = df.parse(string, position);
>     if (date == null || position.getIndex() != string.length()) {
>         throw new FormatException("Date provided does not fit the pattern defined");
>     }
>     return date;
> }
> {code}
> A value that is not longer than the pattern takes exactly the same path as today, so nothing that is accepted today changes. (Requiring the whole value to be used for every value would be stricter than today: for example {{2026-09-30T10:11:12Z}} with the pattern {{yyyy-MM-dd'T'HH:mm:ss}}, 20 characters for a 21 character pattern because of the quotes, is accepted today with the {{Z}} ignored, and would be rejected.) A date followed by other characters is still rejected with the same {{FormatException}} and message (the existing tests {{BindySimpleCsvUnmarshallTest.testMessageWithErroneousDate}} and {{BindySimpleCsvUnmarshallPositionModifiedTest}} pass unchanged).
> Duplicate check (2026-09-30): JIRA "bindy" with "date" and "pattern", "does not fit the pattern", "java.util.Date": only CAMEL-11620 (java.time, fixed) and older unrelated issues. No open pull request touches the Bindy date factories.
> _Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v8.20.10#820010)