[
https://issues.apache.org/jira/browse/LANG-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18035688#comment-18035688
]
Lenny Primak edited comment on LANG-1786 at 11/5/25 11:48 PM:
--------------------------------------------------------------
Very good summary, thank you.
However, there are a couple of important wrinkles missing from it:
# The 3-letter IDs are deprecated for removal. What this usually means is that
they should be removed from all code as soon as possible. If JDK doesn't care
about their compatibility neither should the ecosystem. The JDK team clearly
didn't intend, nor did they want a way to disable this warning.
# The "call site" isn't that clear-cut. For example, the impetus for this
issue isn't anything related to TimeZone specifically, but DateFormatUtils
constructor (see RAT stack trace above), which indirectly collects all
TimeZones and creates parsers for them. Clearly the API is too broad to add
compatibility parameters to all of them, which also has complexity of its own.
was (Author: lprimak):
Very good summary, thank you.
However, there are a couple of important wrinkles missing from it:
# The 3-letter IDs are deprecated for removal. What this usually means is that
they should be removed from all code as soon as possible. If JDK doesn't care
about their compatibility neither should the ecosystem.
# The "call site" isn't that clear-cut. For example, the impetus for this
issue isn't anything related to TimeZone specifically, but DateFormatUtils
constructor (see RAT stack trace above), which indirectly collects all
TimeZones and creates parsers for them. Clearly the API is too broad to add
compatibility parameters to all of them, which also has complexity of its own.
> FastDateFormat logs warnings on the console using FastDateFormat on Java 25
> ---------------------------------------------------------------------------
>
> Key: LANG-1786
> URL: https://issues.apache.org/jira/browse/LANG-1786
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.time.*
> Affects Versions: 3.19.0
> Reporter: Daniel Migowski
> Priority: Major
> Fix For: Patch Needed
>
>
> When using an instance of FastDateFormat with e.g.
> {code:java}
> FastDateFormat.getInstance( "yyyy-MM-dd'T'HH:mm:ssZ" );{code}
> the timezone database of the commons.lang package iterates throught all
> timezones and adds them to the local database. This sadly calls
> {code:java}
> java.util.TimeZone.getTimeZone(String){code}
> with a bunch of timezone strings that are considered deprecated with the new
> JDK25 (or something between 18 and 25, didn't check that), and each of these
> timezone strings leads to a message like
> {noformat}
> WARNING: Use of the three-letter time zone ID "ACT" is deprecated and it will
> be removed in a future release{noformat}
> printed directly from the getTimeZone function to system.err!
> This is actually really annoying. The timezone strings which are deprecated
> can be found in
> {code:java}
> java.time.ZoneId.SHORT_IDS.{code}
> My suggestion is to check in
> {code:java}
> org.apache.commons.lang3.time.FastDateParser.TimeZoneStrategy.TimeZoneStrategy{code}
> if the JDK version 25 is running and then to filter the values from SHORT_IDS
> to be recognized. SHORT_IDS should be copied into commons.lang to make this
> still work with older JDKs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
