Почему отрицательное время перехода на летнее время имеет стандартное название зоны?

Question

Я получаю неправильное имя часового пояса для определенных исторических дат с отрицательным смещением летнего времени.

Обновление в базе данных часовых поясов (tzdata) ввело отрицательное летнее время для зоны Европа / Прага в период с 1946-12-01 по 1947-02-23.

Это источник тздата для Европы / Праги:

# We know of no English-language name for historical Czech winter time;
# abbreviate it as "GMT", as it happened to be GMT.

...

            1:00    Czech   CE%sT   1946 Dec  1  3:00
# Vanguard section, for zic and other parsers that support negative DST.
            1:00    -1:00   GMT 1947 Feb 23  2:00
# Rearguard section, for parsers that do not support negative DST.
#           0:00    -   GMT 1947 Feb 23  2:00

Эта новая база данных находится в Java 8 начиная с u181.

При использовании времени в указанном периоде я получаю неправильное имя часового пояса как "CET" / "Центральноевропейское время" вместо GMT, как указано в tzdata.

Long timeInMilis = Long.parseLong("-725328000000");
String pattern = "yyyy-MM-dd HH:mm:ss zzz";
TimeZone.setDefault(TimeZone.getTimeZone(("Europe/Berlin")));
System.out.println(new SimpleDateFormat(pattern).format(new Date(timeInMilis)));
TimeZone.setDefault(TimeZone.getTimeZone(("Europe/Prague")));
System.out.println(new SimpleDateFormat(pattern).format(new Date(timeInMilis)));

Результат

1947-01-07 01:00:00 CET
1947-01-07 00:00:00 CET

Первый ряд для часового пояса Берлина, второй для Праги. Оба говорят, что это CET, но для Праги это неправильно. Следует указать время по Гринвичу, как указано в базе данных часовых поясов

Answer 1

По крайней мере, насколько я вижу в истории этой проблемы для OpenJDK ...

https://bugs.openjdk.java.net/browse/JDK-8195595?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel

... OpenJDK до сих пор избегал иметь дело с отрицательным DSTс использованием «тыловой» версии tzdata, версии, в которой нет отрицательного DST (опция, которая, вероятно, скоро исчезнет).

Я подозреваю, что в Oracle до сих пор избегали иметь дело с отрицательным DST.тоже.

Во всяком случае, я не думаю, что реализация часовых поясов в Java хорошо обрабатывает эти сокращения часовых поясов.Я попробовал этот пример кода:

    SimpleDateFormat  format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss zzz");

    format.setTimeZone(TimeZone.getTimeZone(("Europe/Prague")));

    for (int date = 1; date <= 28; ++date) {
      System.out.println(format.format(new GregorianCalendar(1947, 1, date, 0, 0).getTime()));
    }

... и обозначение остается "CET" до и после предполагаемой даты перехода.

...
1947-02-20 05:00:00 CET
1947-02-21 05:00:00 CET
1947-02-22 05:00:00 CET
1947-02-23 06:00:00 CET
1947-02-24 06:00:00 CET
1947-02-25 06:00:00 CET
1947-02-26 06:00:00 CET
...

Если я правильно помню,Реализация часовых поясов в Java вообще не сохраняет историческую запись об этих изменениях аббревиатур, она просто кодирует времена перехода для изменений смещения часового пояса.Отображаемые сокращения отображаются в соответствии с текущими, а не историческими стандартами.

Редактировать: Я прочитал tzdata неправильно и ошибся в том, что это значит!