Description:
Starting with JDK 25, java.util.TimeZone.getTimeZone(String) prints a deprecation warning to stderr whenever it is called with one of the legacy three-letter time zone IDs (see the JDK 25 TimeZone javadoc and ZoneId.SHORT_IDS):
WARNING: Use of the three-letter time zone ID "IST" is deprecated and it will be removed in a future release
Connector/J triggers this warning during session time zone detection. When the MySQL server reports time_zone / system_time_zone as a legacy three-letter abbreviation (e.g. IST, CST, PST), the warning is printed by the driver on connection setup. Applications that were silent on JDK 21 now emit these warnings on JDK 25 with no code change.
Root cause: com.mysql.cj.util.TimeUtil.loadTimeZoneMappings() first loads the curated TimeZoneMapping.properties (whose values are all full IANA names), but then bridges every ID returned by TimeZone.getAvailableIDs() as an identity mapping:
// Bridge all Time Zones known by Java.
for (String tz : TimeZone.getAvailableIDs()) {
timeZoneMappings.put(tz, tz);
}
TimeZone.getAvailableIDs() still includes the deprecated three-letter IDs, so e.g. IST is mapped to itself, and NativeServerSession.getSessionTimeZone() subsequently calls TimeZone.getTimeZone("IST") — producing the JDK warning.
Two additional consequences:
(1) the identity bridge bypasses the driver's own policy of rejecting ambiguous abbreviations — CEST correctly fails with "unrecognized time zone", but IST (ambiguous between Israel, India, and Ireland) silently resolves through the JDK legacy mapping to Asia/Kolkata rules.
(2) the JDK states these IDs will be removed, at which point today's silent resolution becomes a hard connection failure.
How to repeat:
Run any client on JDK 25 against a server whose system_time_zone is a legacy abbreviation (with time_zone = SYSTEM); the warning appears on stderr during connection setup.
Suggested fix:
In TimeUtil.loadTimeZoneMappings(), translate the deprecated three-letter IDs through the JDK's own java.time.ZoneId.SHORT_IDS map — the same mapping TimeZone.getTimeZone applies internally — so resolution behavior is unchanged but the raw abbreviation never reaches TimeZone.getTimeZone():
// Bridge all Time Zones known by Java.
for (String tz : TimeZone.getAvailableIDs()) {
String canonical = java.time.ZoneId.SHORT_IDS.getOrDefault(tz, tz);
if (canonical.startsWith("+") || canonical.startsWith("-")) {
canonical = "GMT" + canonical; // EST/MST/HST map to bare offsets like "-05:00"
}
timeZoneMappings.putIfAbsent(tz, canonical);
}
Notes:
(1) The offset guard is required because ZoneId.SHORT_IDS maps EST/MST/ HST to bare offsets ("-05:00" etc.), which TimeZone.getTimeZone(String) does not parse (it would silently fall back to GMT). Prefixing "GMT" preserves the current fixed-offset semantics.
(2) putIfAbsent (instead of put) additionally stops the bridge from overwriting curated entries of TimeZoneMapping.properties whose keys are also Java zone IDs.
(3) This also future-proofs the driver for the announced removal of three-letter IDs from the JDK.
© 2026, Oracle Corporation and/or its affiliates
Description: Starting with JDK 25, java.util.TimeZone.getTimeZone(String) prints a deprecation warning to stderr whenever it is called with one of the legacy three-letter time zone IDs (see the JDK 25 TimeZone javadoc and ZoneId.SHORT_IDS): WARNING: Use of the three-letter time zone ID "IST" is deprecated and it will be removed in a future release Connector/J triggers this warning during session time zone detection. When the MySQL server reports time_zone / system_time_zone as a legacy three-letter abbreviation (e.g. IST, CST, PST), the warning is printed by the driver on connection setup. Applications that were silent on JDK 21 now emit these warnings on JDK 25 with no code change. Root cause: com.mysql.cj.util.TimeUtil.loadTimeZoneMappings() first loads the curated TimeZoneMapping.properties (whose values are all full IANA names), but then bridges every ID returned by TimeZone.getAvailableIDs() as an identity mapping: // Bridge all Time Zones known by Java. for (String tz : TimeZone.getAvailableIDs()) { timeZoneMappings.put(tz, tz); } TimeZone.getAvailableIDs() still includes the deprecated three-letter IDs, so e.g. IST is mapped to itself, and NativeServerSession.getSessionTimeZone() subsequently calls TimeZone.getTimeZone("IST") — producing the JDK warning. Two additional consequences: (1) the identity bridge bypasses the driver's own policy of rejecting ambiguous abbreviations — CEST correctly fails with "unrecognized time zone", but IST (ambiguous between Israel, India, and Ireland) silently resolves through the JDK legacy mapping to Asia/Kolkata rules. (2) the JDK states these IDs will be removed, at which point today's silent resolution becomes a hard connection failure. How to repeat: Run any client on JDK 25 against a server whose system_time_zone is a legacy abbreviation (with time_zone = SYSTEM); the warning appears on stderr during connection setup. Suggested fix: In TimeUtil.loadTimeZoneMappings(), translate the deprecated three-letter IDs through the JDK's own java.time.ZoneId.SHORT_IDS map — the same mapping TimeZone.getTimeZone applies internally — so resolution behavior is unchanged but the raw abbreviation never reaches TimeZone.getTimeZone(): // Bridge all Time Zones known by Java. for (String tz : TimeZone.getAvailableIDs()) { String canonical = java.time.ZoneId.SHORT_IDS.getOrDefault(tz, tz); if (canonical.startsWith("+") || canonical.startsWith("-")) { canonical = "GMT" + canonical; // EST/MST/HST map to bare offsets like "-05:00" } timeZoneMappings.putIfAbsent(tz, canonical); } Notes: (1) The offset guard is required because ZoneId.SHORT_IDS maps EST/MST/ HST to bare offsets ("-05:00" etc.), which TimeZone.getTimeZone(String) does not parse (it would silently fall back to GMT). Prefixing "GMT" preserves the current fixed-offset semantics. (2) putIfAbsent (instead of put) additionally stops the bridge from overwriting curated entries of TimeZoneMapping.properties whose keys are also Java zone IDs. (3) This also future-proofs the driver for the announced removal of three-letter IDs from the JDK.