我得到的特定历史日期的错误时区名称，DST偏移量为负。
时区数据库 (tzdata) 的更新在 1946-12-01 到 1947-02-23 期间为欧洲/布拉格区域引入了负 DST。
这是欧洲/布拉格的tzdata来源：
# 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
这个新数据库自 u181 起在 Java 8 中。
在指定时间段内使用时间时，我得到错误的时区名称为"CET"/"中欧时间"，而不是 tzdata 中所述的 GMT。
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，但对布拉格来说这是错误的。它应该说GMT，如时区数据库中提到的
至少据我在 OpenJDK 的这个问题的历史中看到的......
https://bugs.openjdk.java.net/browse/JDK-8195595?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
。到目前为止，OpenJDK通过使用tzdata的"后卫"版本来避免处理负DST，该版本没有负DST(显然很快就会消失)。
我怀疑到目前为止，Oracle的Java也一直在避免处理负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，并误解了它的含义！