We have added https://github.com/unicode-org/cldr/commit/f0c81c482a6a280c26d3369e925e1a0e60c0fd9e to the current CLDR release's maintenance branch, but we're not currently planning a release for it. openjdk could cherry-pick that.
With this commit, Edmonton at -6 will display as MDT. On Tue, 21 Jul 2026 at 22:31, Paul Eggert via tz <[email protected]> wrote: > On 2026-07-20 22:28, sorav.sahu--- via tz wrote: > > I updated the tzdata2026c patch in my openjdk 11.0.31 2026-04-21 LTS. > However, when I ran the jShell commands to check the abbreviation, it still > shows MST and MDT both. Are we expecting a new patch for the same? as > offset is -06:00 but it shows MST. > > I assume you're talking about the America/Edmonton timezone. Updating to > TZDB 2026c should mean that America/Edmonton will be at -06 for the > indefinite future, so if you're seeing -06 for current and future (i.e., > winter) timestamps your UTC offsets should be good. > > For time zone abbreviations like "MST" and "MDT", OpenJDK uses CLDR > which has not yet been updated for America/Edmonton. As I understand it, > CLDR runs on a 6-month release cycle and if the past is a guide their > next release should arrive late October. Until then you may see > confusing or inaccurate time zone abbreviations and localizations for > America/Edmonton. Although we've been in contact with the CLDR folks, I > don't know what they're doing about Edmonton. You can try contacting > them yourself by following the instructions in > <https://cldr.unicode.org/requesting_changes>. > > In this period of confusion I suggest avoiding abbreviations like "MST" > as they are becoming ambiguous. Use numeric offsets like "-06" instead. > If you do that, it won't matter what TZDB and CLDR do about the > abbreviations. >
