[
https://issues.apache.org/jira/browse/WW-5814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-5814:
------------------------------
Fix Version/s: 7.5.0
Description:
{{DateConverter}} accepts ISO date-times such as {{1996-12-19T16:39:57Z}} and
{{2026-10-25T05:14:42.000Z}} (the form JavaScript's {{Date.toISOString()}}
produces) for {{java.util.Date}} properties, but treats the {{Z}} as a literal.
The value is interpreted in the server's default time zone, so a UTC timestamp
sent by a client is shifted by the server's offset.
Other RFC 3339 forms are not accepted at all: a numeric offset ({{+02:00}}),
and fractional seconds with other than three digits.
h2. Background
Before WW-5813 the converter ignored any text after {{yyyy-MM-dd'T'HH:mm:ss}},
so {{Z}} and {{.SSSZ}} were silently dropped. WW-5813 rejects trailing text,
and keeps these two inputs working by adding {{yyyy-MM-dd'T'HH:mm:ss'Z'}} and
{{yyyy-MM-dd'T'HH:mm:ss.SSS'Z'}} formats that preserve the previous local-time
reading. {{OgnlUtilTest.testSetPropertiesDate}} pins that reading.
h2. Fix
Reading {{Z}} as UTC changes the instant every existing {{...Z}} value converts
to (shifted by the server's offset), silently and without a conversion error,
so it goes behind an opt-in flag:
* new constant {{struts.converter.date.isoOffsetAware}}, default {{false}}
* {{false}}: behaviour as released after WW-5813, {{Z}} read as server-local
time
* {{true}}: for {{java.util.Date}} (and {{Calendar}}, which goes through it) an
ISO date-time with an offset is parsed with
{{DateTimeFormatter.ISO_OFFSET_DATE_TIME}}, so {{Z}} means UTC, numeric offsets
are honoured and 0-9 fractional digits are accepted
{{java.sql.Timestamp}} (no ISO support today), the {{java.time}} types
({{OffsetDateTime}} already parses offsets) and the JSON plugin's own date
handling are out of scope.
The default flips to {{true}} in 8.0.0 under a separate ticket.
was:
{{DateConverter}} accepts ISO date-times such as {{1996-12-19T16:39:57Z}} and
{{2026-10-25T05:14:42.000Z}} (the form JavaScript's {{Date.toISOString()}}
produces) for {{java.util.Date}} properties, but treats the {{Z}} as a literal.
The value is interpreted in the server's default time zone, so a UTC timestamp
sent by a client is shifted by the server's offset.
Other RFC 3339 forms are not accepted at all: a numeric offset ({{+02:00}}),
and fractional seconds with other than three digits.
h2. Background
Before WW-5813 the converter ignored any text after {{yyyy-MM-dd'T'HH:mm:ss}},
so {{Z}} and {{.SSSZ}} were silently dropped. WW-5813 rejects trailing text,
and keeps these two inputs working by adding {{yyyy-MM-dd'T'HH:mm:ss'Z'}} and
{{yyyy-MM-dd'T'HH:mm:ss.SSS'Z'}} formats that preserve the previous local-time
reading. {{OgnlUtilTest.testSetPropertiesDate}} pins that reading.
h2. Possible fix
Parse ISO date-times with their offset ({{XXX}}, or
{{DateTimeFormatter.ISO_OFFSET_DATE_TIME}} / {{ISO_INSTANT}}), so {{Z}} means
UTC, and accept numeric offsets and variable fractional seconds.
This is a behaviour change: any {{...Z}} value converts to a different instant
than today (shifted by the server's offset), so it must be called out in the
release notes.
> DateConverter reads a trailing Z in an ISO date-time as server-local time
> instead of UTC
> ----------------------------------------------------------------------------------------
>
> Key: WW-5814
> URL: https://issues.apache.org/jira/browse/WW-5814
> Project: Struts 2
> Issue Type: Bug
> Components: Core
> Reporter: Lukasz Lenart
> Priority: Major
> Fix For: 7.5.0
>
>
> {{DateConverter}} accepts ISO date-times such as {{1996-12-19T16:39:57Z}} and
> {{2026-10-25T05:14:42.000Z}} (the form JavaScript's {{Date.toISOString()}}
> produces) for {{java.util.Date}} properties, but treats the {{Z}} as a
> literal. The value is interpreted in the server's default time zone, so a UTC
> timestamp sent by a client is shifted by the server's offset.
> Other RFC 3339 forms are not accepted at all: a numeric offset ({{+02:00}}),
> and fractional seconds with other than three digits.
> h2. Background
> Before WW-5813 the converter ignored any text after
> {{yyyy-MM-dd'T'HH:mm:ss}}, so {{Z}} and {{.SSSZ}} were silently dropped.
> WW-5813 rejects trailing text, and keeps these two inputs working by adding
> {{yyyy-MM-dd'T'HH:mm:ss'Z'}} and {{yyyy-MM-dd'T'HH:mm:ss.SSS'Z'}} formats
> that preserve the previous local-time reading.
> {{OgnlUtilTest.testSetPropertiesDate}} pins that reading.
> h2. Fix
> Reading {{Z}} as UTC changes the instant every existing {{...Z}} value
> converts to (shifted by the server's offset), silently and without a
> conversion error, so it goes behind an opt-in flag:
> * new constant {{struts.converter.date.isoOffsetAware}}, default {{false}}
> * {{false}}: behaviour as released after WW-5813, {{Z}} read as server-local
> time
> * {{true}}: for {{java.util.Date}} (and {{Calendar}}, which goes through it)
> an ISO date-time with an offset is parsed with
> {{DateTimeFormatter.ISO_OFFSET_DATE_TIME}}, so {{Z}} means UTC, numeric
> offsets are honoured and 0-9 fractional digits are accepted
> {{java.sql.Timestamp}} (no ISO support today), the {{java.time}} types
> ({{OffsetDateTime}} already parses offsets) and the JSON plugin's own date
> handling are out of scope.
> The default flips to {{true}} in 8.0.0 under a separate ticket.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
