[
https://issues.apache.org/jira/browse/WW-5812?focusedWorklogId=1049927&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1049927
]
ASF GitHub Bot logged work on WW-5812:
--------------------------------------
Author: ASF GitHub Bot
Created on: 24/Oct/26 15:00
Start Date: 24/Oct/26 15:00
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #2057:
URL: https://github.com/apache/struts/pull/2057
Fixes [WW-5812](https://issues.apache.org/jira/browse/WW-5812)
## Problem
`input type="date"` always submits `yyyy-MM-dd`. Converting that to
`java.util.Date` failed with `TypeConversionException: Could not parse date`
under some locales and global formats, although ISO `yyyy-MM-dd` is in the
converter's format list:
| Setting | `"2026-10-24"` → `java.util.Date` |
|---|---|
| locale `nl-NL` | `Could not parse date` |
| global `struts.date.format=dd-MM-yyyy`, any locale | `Could not parse
date` |
| `en-US`, `pl-PL` | 2026-10-24 |
The selection loop picked the **first format that parsed leniently**, then
re-parsed strictly with that one and threw when it failed, never trying the
rest. `dd-MM-y` (nl-NL SHORT) leniently reads `2026-10-24` as 18 Apr 2030, so
it won, and the ISO format later in the list was never reached.
## Fix
The `java.util.Date` and `java.sql.Timestamp` branches share a new
`selectFormat`: the first format that **strictly parses the whole input** wins;
when none does, it falls back to the previous first-lenient pick, which the
caller still re-parses strictly.
- **Whole input**, not just strict: `SimpleDateFormat.parse(String)` ignores
trailing text, so a strict-only rule would let a date-only format match the
prefix of `24-10-2026 25:00:00` and silently drop the invalid hour. With the
whole-input rule that input still fails.
- Format order is unchanged, so a configured global format still takes
precedence.
- Anything that converted before converts to the same value, with one
exception: a date-time under a date-only global format (e.g. `24-10-2026
10:15:30` with `dd-MM-yyyy`) now keeps its time instead of the date-only prefix
match turning it into midnight. Worth a line in the 7.5.0 notes.
- `Timestamp`: no input found where the result changes (its formats run
most-specific first and include no ISO format); it uses the shared helper for
consistency, and a test pins the `nl-NL` behaviour.
- The `java.time` branch is unaffected: `DateTimeFormatter` rejects the ISO
string under these patterns.
Checked against the old logic across 7 locales × 3 global-format settings ×
15 inputs (incl. garbage, invalid time, trailing text): every difference is a
previous `THROWS` becoming the correct date, plus the time-keeping case above.
## Tests
`DateConverterTest`: ISO date under `nl-NL`; ISO date and date-time under a
`dd-MM-yyyy` global format; date-time keeping its time under a date-only global
format (all failed before); invalid hour still rejected and `nl-NL` `Timestamp`
pinned. Full core suite green (3567).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1049927)
Remaining Estimate: 0h
Time Spent: 10m
> DateConverter rejects valid ISO yyyy-MM-dd dates when a lenient-only format
> matches first
> -----------------------------------------------------------------------------------------
>
> Key: WW-5812
> URL: https://issues.apache.org/jira/browse/WW-5812
> Project: Struts 2
> Issue Type: Bug
> Components: Core
> Reporter: Lukasz Lenart
> Priority: Major
> Fix For: 7.5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Problem
> {{input type="date"}} always submits {{yyyy-MM-dd}}. When {{DateConverter}}
> converts that value to {{java.util.Date}}, it rejects it under some locales
> and global patterns with {{TypeConversionException: Could not parse date}},
> even though ISO {{yyyy-MM-dd}} is one of the formats it supports.
> ||Locale||{{"2026-10-24"}} → {{java.util.Date}}||
> |{{nl-NL}}|{{TypeConversionException: Could not parse date}}|
> |{{en-US}}, {{pl-PL}}|2026-10-24 (correct)|
> The format-selection loop picks the *first format that parses leniently*. It
> then re-parses the input *strictly* with that one format and throws when the
> strict parse fails. It never tries the remaining formats. Under {{nl-NL}} the
> locale SHORT pattern {{dd-MM-y}} leniently accepts {{2026-10-24}} (as 18 Apr
> 2030), so it is selected; the strict re-parse then fails, and the ISO format
> later in the list is never tried. A global {{struts.date.format}} with {{-}}
> separators, such as {{dd-MM-yyyy}}, fails the same way.
> The {{java.sql.Timestamp}} branch uses the same lenient-select /
> strict-re-parse structure. The {{java.time}} branch is not affected:
> {{DateTimeFormatter}} rejects the ISO string under these patterns, so ISO is
> reached.
> An earlier version of this ticket said the value was silently misparsed.
> Probing the real converter showed the result is a conversion error instead.
> This affects {{textfield type="date"}} bound to a {{java.util.Date}}
> property, and {{datetextfield}} in the html5 theme (WW-5778).
> h2. Proposal
> Select the format *strictly* in the {{java.util.Date}} and
> {{java.sql.Timestamp}} branches, so a format that only matches leniently is
> skipped and the remaining formats are tried.
> * Format order is unchanged, so a configured global format still takes
> precedence
> * Any input that converts today converts to the same value: a strict match is
> always a lenient match, so the first strict match is the format selected today
> * Inputs that currently throw because a lenient-only format was selected will
> now convert
> Tests: {{nl-NL}} locale and a {{dd-MM-yyyy}} global format for
> {{java.util.Date}}, the {{Timestamp}} branch, and existing inputs unchanged.
> Related: WW-5778
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
