[
https://issues.apache.org/jira/browse/WW-5813?focusedWorklogId=1049993&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1049993
]
ASF GitHub Bot logged work on WW-5813:
--------------------------------------
Author: ASF GitHub Bot
Created on: 25/Oct/26 06:06
Start Date: 25/Oct/26 06:06
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #2058:
URL: https://github.com/apache/struts/pull/2058
Fixes [WW-5813](https://issues.apache.org/jira/browse/WW-5813)
## Problem
`DateConverter` parsed with `SimpleDateFormat.parse(String)`, which stops at
the end of the pattern and ignores the rest of the input. When a date-time's
separator did not match the locale's date-time pattern, no date-time format
matched, the converter fell back to the date-only format, and the value
silently became midnight:
| Input (`nl-NL`) | JDK | Before | After |
|---|---|---|---|
| `24-10-2026 10:15:30` | 25 (pattern is `dd-MM-y, HH:mm:ss`) | `2026-10-24
00:00` | conversion error |
| `24-10-2026 25:00:00` | 25 | `2026-10-24 00:00` | conversion error |
| `24-10-2026 at 10:15:30` | any | `2026-10-24 00:00` | conversion error |
| `10:15:30 tomorrow` (`Time`) | any | `10:15:30` | conversion error |
## Change
- The final strict parse must consume the whole input (`ParsePosition`
check), for `java.util.Date`, `java.sql.Timestamp` and `java.sql.Time`.
- `selectFormat`'s lenient fallback is removed. Whatever it picked had
already failed the strict whole-input parse, so it could only end in the same
error. `selectFormat` now returns `null` when no format strictly parses the
whole input.
- ISO date-times ending in `Z` converted before only because the `Z` was
ignored. Two formats, `yyyy-MM-dd'T'HH:mm:ss'Z'` and
`yyyy-MM-dd'T'HH:mm:ss.SSS'Z'` (what `Date.toISOString()` produces), keep them
converting with the same server-local reading as before. Reading `Z` as UTC
changes the stored instant, so it is split out to
[WW-5814](https://issues.apache.org/jira/browse/WW-5814).
## Tests
- New: trailing text rejected for `Date`, `Timestamp` and `Time`; `...Z` and
`...SSSZ` accepted. The inputs avoid every locale pattern, so the results do
not depend on the JDK.
- `testSqlTimeType` and `testSqlTimestampType` only passed because of the
ignored trailing text: ` AM` under a 24-hour pattern on JDK 17, and a date-only
prefix match on JDK 25. Their inputs are now formatted with the locale's own
pattern.
- `OgnlUtilTest.testSetPropertiesDate` (`1996-12-19T16:39:57Z` into `Date`
and `Calendar`) passes unchanged.
- Full core suite on JDK 17 and JDK 25, plus the spring, junit,
javatemplates and json plugins on JDK 17, all green.
## Release notes (7.5.0)
- Date, timestamp and time input with text after a valid value is now
rejected instead of being truncated.
- ISO date-times with milliseconds and a trailing `Z` now keep their
milliseconds.
- `DateConverter#selectFormat` (protected) no longer falls back to a lenient
match.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1049993)
Remaining Estimate: 0h
Time Spent: 10m
> DateConverter silently drops the time when the date-time separator does not
> match the locale pattern
> ----------------------------------------------------------------------------------------------------
>
> Key: WW-5813
> URL: https://issues.apache.org/jira/browse/WW-5813
> Project: Struts 2
> Issue Type: Bug
> Components: Core
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 7.5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a {{java.util.Date}} (or {{java.sql.Timestamp}}) property receives a
> date-time whose separator between date and time differs from the locale's
> date-time pattern, {{DateConverter}} converts it to midnight of that date
> instead of rejecting it.
> h2. Example
> On JDK 25 the {{nl-NL}} SHORT/MEDIUM date-time pattern is {{dd-MM-y,
> HH:mm:ss}} (JDK 17/21: {{dd-MM-y HH:mm:ss}}, the comma came with newer CLDR
> data). Submitting
> {code}24-10-2026 10:15:30
> {code}
> to a {{Date}} property under {{nl-NL}} on JDK 25 yields {{2026-10-24
> 00:00:00}}. The time is lost without any conversion error. An invalid time is
> accepted the same way: {{24-10-2026 25:00:00}} also becomes midnight.
> h2. Cause
> No date-time format matches the whole input, so the converter falls back to a
> date-only format ({{dd-MM-y}}). {{SimpleDateFormat.parse(String)}} stops at
> the end of the date and ignores the trailing text, so the strict re-parse
> succeeds on the prefix.
> This exists on {{main}} before WW-5812; WW-5812 only changed which format is
> selected when one matches the whole input.
> h2. Possible fix
> Require the final parse to consume the whole input (a {{ParsePosition}}
> check, as WW-5812's format selection already does), and throw
> {{TypeConversionException}} otherwise.
> This is a behaviour change: any input with trailing text after a valid date,
> which converts today, would then be rejected. It should be called out in the
> release notes.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
