在 IANA 数据库和 Java tzdb.dat 2019c 数据库的 Africa/Casablanca 时区之间存在夏令时差异，这让我感到非常困惑。也许还有其他情况，但我只发现了这一个。从我所知道的情况来看，IANA 时区数据库清楚地显示摩洛哥 (Africa/Casablanca) 支持夏令时，不幸的是，Java 时区数据库 tzdb.dat 在 2019c 版本中并不同意。这已经并将会给我带来无限的痛苦。我错过了什么，或者其他人是否遇到过类似的情况。
IANA 表格 2019c 的 Africa/Casablanca 区域
注意：下面表格的部分显示正常时间为 UTC+1，夏令时时间为UTC，斜杠(/)分隔标准和夏令时的缩写
自2018年10月28日至今，标准时间偏移量为+1，夏令时偏移量为+0（斜杠/分隔标准和夏令时缩写）。 STDOFF 1:00指将其添加到UT以获得标准时间的时间量，没有任何关于夏令时的调整，这对应于UTC +1，即当前的摩洛哥时间。 因此，我们采用Zone Africa / Casablanca，它是UTC，并添加偏移+01 / +00，具体取决于斋月。
我编写了一个简单的Java类来检查2019c TZDB。该类（如下所示）显示最新的Java时区数据文件tzdb.dat文件出现了问题。这个测试使用IBM SR5FP40和时区2019c数据文件运行。使用2019c数据文件的OpenJDK也有相同的结果。
tzdb.dat的第一行显示2019c TZDB 2019cX Africa/Abidjan Africa/Accra Africa/Addis_Ababa Africa/Algiers
显示问题的测试
时区=Africa/Casablanca 支持夏令时=false 日期Mon May 20 00:00:00 WET 2019目前不在DST中 时区名西欧时间 时区ID Africa/Casablanca
还运行了基准测试以显示代码是否支持夏令时。
时区=Europe/Rome 支持夏令时=true 日期Mon May 20 00:00:00 CEST 2019目前在DST中 时区名中欧时间 时区ID Europe/Rome 代码供参考。
IANA 表格 2019c 的 Africa/Casablanca 区域
注意：下面表格的部分显示正常时间为 UTC+1，夏令时时间为UTC，斜杠(/)分隔标准和夏令时的缩写
区域 名称 标准偏移 规则 格式 [直至]
区域 Africa/Casablanca -0:30:20 - LMT 1913年10月26日 0:00 Morocco +00/+01 1984 Mar 16
1:00 - +01 1986
0:00 Morocco +00/+01 2018 Oct 28 3:00
1:00 Morocco +01/+00
自2018年10月28日至今，标准时间偏移量为+1，夏令时偏移量为+0（斜杠/分隔标准和夏令时缩写）。 STDOFF 1:00指将其添加到UT以获得标准时间的时间量，没有任何关于夏令时的调整，这对应于UTC +1，即当前的摩洛哥时间。 因此，我们采用Zone Africa / Casablanca，它是UTC，并添加偏移+01 / +00，具体取决于斋月。
我编写了一个简单的Java类来检查2019c TZDB。该类（如下所示）显示最新的Java时区数据文件tzdb.dat文件出现了问题。这个测试使用IBM SR5FP40和时区2019c数据文件运行。使用2019c数据文件的OpenJDK也有相同的结果。
tzdb.dat的第一行显示2019c TZDB 2019cX Africa/Abidjan Africa/Accra Africa/Addis_Ababa Africa/Algiers
显示问题的测试
时区=Africa/Casablanca 支持夏令时=false 日期Mon May 20 00:00:00 WET 2019目前不在DST中 时区名西欧时间 时区ID Africa/Casablanca
还运行了基准测试以显示代码是否支持夏令时。
时区=Europe/Rome 支持夏令时=true 日期Mon May 20 00:00:00 CEST 2019目前在DST中 时区名中欧时间 时区ID Europe/Rome 代码供参考。
import java.util.*;
import java.text.SimpleDateFormat;
import java.text.ParseException;
public class checkdaylight{
public static void main(String[] args)
{
// Create TimeZone object
//Europe/Rome
//Pacific/Pago_Pago
//Africa/Casablanca
String TimezoneToTest = "Africa/Casablanca";
System.out.println("Time Zone = " + TimezoneToTest);
TimeZone obj = TimeZone.getTimeZone(TimezoneToTest);
TimeZone.setDefault(TimeZone.getTimeZone(TimezoneToTest)); //to avoid confusion
// Checking day light time
// and displaying the result
System.out.println("Supports Day light Savings time = "
+ obj.useDaylightTime());
String pattern = "yyyy-MM-dd";
SimpleDateFormat simpleDateFormat = new SimpleDateFormat(pattern);
try{
simpleDateFormat.setTimeZone(TimeZone.getTimeZone(TimezoneToTest));
Date checkdate = simpleDateFormat.parse("2019-05-20");
System.out.println("Date " + checkdate.toString()+ " is currently in DST "+ obj.inDaylightTime(checkdate));
} catch (ParseException e) {
e.printStackTrace();
}
System.out.println("Time zone name " +obj.getDisplayName());
System.out.println("Time zone ID " + obj.getID());
}
}
TimeZone、SimpleDateFormat和Date。这些类设计得很糟糕并且非常过时，尤其是SimpleDateFormat经常出问题。相反，使用 java.time，现代 Java 日期和时间 API 中的ZoneId、ZonedDateTime和DateTimeFormatter。 - Ole V.V.