[
https://issues.apache.org/jira/browse/LANG-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Migowski updated LANG-1786:
----------------------------------
Description:
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.
was:
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.
> A lot of warnings on the console when using FastDateFormat with JDK25
> ---------------------------------------------------------------------
>
> Key: LANG-1786
> URL: https://issues.apache.org/jira/browse/LANG-1786
> Project: Commons Lang
> Issue Type: Bug
> 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)
