[
https://issues.apache.org/jira/browse/WW-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-5812:
------------------------------
Description:
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
was:
h2. Problem
{{input type="date"}} always submits {{yyyy-MM-dd}}. When {{DateConverter}}
converts that value to {{java.util.Date}}, it tries the formats in this order:
the global {{struts.date.format}} pattern, then the locale date-time and
SHORT/MEDIUM/LONG date formats, and only then ISO {{yyyy-MM-dd}}. All of these
are lenient {{SimpleDateFormat}}s, so an earlier pattern with {{-}} separators
accepts the ISO string and returns a wrong date. No conversion error is raised.
||Pattern source||Pattern||{{2026-10-24}} parses to||
|{{struts.date.format=dd-MM-yyyy}}|{{dd-MM-yyyy}}|18 Apr 0030|
|locale {{nl_NL}} SHORT|{{dd-MM-y}}|18 Apr 2030|
|{{en_US}}, {{en_GB}}, {{de_DE}}, {{pl_PL}}|{{/}} or {{.}} separators|fails,
falls through to ISO (correct)|
This already affects {{textfield type="date"}} bound to a {{java.util.Date}}
property, and it will affect {{datetextfield}} in the html5 theme (WW-5778).
h2. Proposal
When the submitted string matches the ISO local date (or date-time) shape
exactly, parse it as ISO before trying the global and locale patterns. Add
tests that cover the {{nl_NL}} locale and a {{dd-MM-yyyy}} global pattern, and
check that non-ISO input still goes through the existing order.
Related: WW-5778
> 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
>
>
> 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)
