java.time：CET 时区是否考虑夏令时？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/26886703/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
java.time: Does the CET time zone considers daylight saving time?
提问by FrVaBe
I use the new java.timeimplementation of Java 8 and wonder about the output of a UTC to CETtime conversion result.
我使用java.timeJava 8的新实现并想知道 UTC 到CET时间转换结果的输出。
ZonedDateTime utcTime = ZonedDateTime.of(2014, 7, 1, 8, 0, 0, 0, ZoneId.of("UTC"));
ZonedDateTime cetTime = ZonedDateTime.ofInstant(utcTime.toInstant(), ZoneId.of("CET"));
System.out.println("Summer-UTC-Time: " + utcTime);
System.out.println("Summer-CET-Time: " + cetTime);
System.out.println();
utcTime = ZonedDateTime.of(2014, 1, 1, 8, 0, 0, 0, ZoneId.of("UTC"));
cetTime = ZonedDateTime.ofInstant(utcTime.toInstant(), ZoneId.of("CET"));
System.out.println("Winter-UTC-Time: " + utcTime);
System.out.println("Winter-CET-Time: " + cetTime);
I expected that the CET time would always be +1 of the UTC time but instead I got:
我希望 CET 时间总是 UTC 时间的 +1，但我得到了：
Summer-UTC-Time: 2014-07-01T08:00Z[UTC]
Summer-CET-Time: 2014-07-01T10:00+02:00[CET] -> +2 **Unexpected**
Winter-UTC-Time: 2014-01-01T08:00Z[UTC]
Winter-CET-Time: 2014-01-01T09:00+01:00[CET] -> +1 Expected
So apparently I have to deal with daylight saving time which I did not expect when using CET. Is the java.timeCET in truth CEST? And if yes, what zone should I use if I need CET?
所以显然我必须处理夏令时，这是我在使用 CET 时没想到的。是java.time真理CET CEST？如果是，如果我需要 CET，我应该使用哪个区域？
回答by JodaStephen
The IANA definition of CETis that it follows the time-zone rules of Central Europe, which includes both winter and summer time. The rules can be seen here, which shows that "CET" is based on "C-Eur"which includes summer time.
该CET的IANA定义是，它遵循中欧，其中包括冬季和夏季时间的时区规则。规则可以在这里看到，这表明“CET”基于“C-Eur”，其中包括夏令时。
In java.timeyou can also see the full set of rules:
在java.time您还可以看到完整的规则集：
ZoneId zone = ZoneId.of("CET");
System.out.println(zone);
System.out.println(zone.getRules());
for (ZoneOffsetTransition trans : zone.getRules().getTransitions()) {
System.out.println(trans);
}
for (ZoneOffsetTransitionRule rule : zone.getRules().getTransitionRules()) {
System.out.println(rule);
}
which prints:
打印：
CET
ZoneRules[currentStandardOffset=+01:00]
Transition[Gap at 1916-04-30T23:00+01:00 to +02:00]
Transition[Overlap at 1916-10-01T01:00+02:00 to +01:00]
Transition[Gap at 1917-04-16T02:00+01:00 to +02:00]
Transition[Overlap at 1917-09-17T03:00+02:00 to +01:00]
Transition[Gap at 1918-04-15T02:00+01:00 to +02:00]
Transition[Overlap at 1918-09-16T03:00+02:00 to +01:00]
Transition[Gap at 1940-04-01T02:00+01:00 to +02:00]
Transition[Overlap at 1942-11-02T03:00+02:00 to +01:00]
Transition[Gap at 1943-03-29T02:00+01:00 to +02:00]
Transition[Overlap at 1943-10-04T03:00+02:00 to +01:00]
Transition[Gap at 1944-04-03T02:00+01:00 to +02:00]
Transition[Overlap at 1944-10-02T03:00+02:00 to +01:00]
Transition[Gap at 1945-04-02T02:00+01:00 to +02:00]
Transition[Overlap at 1945-09-16T03:00+02:00 to +01:00]
Transition[Gap at 1977-04-03T02:00+01:00 to +02:00]
Transition[Overlap at 1977-09-25T03:00+02:00 to +01:00]
Transition[Gap at 1978-04-02T02:00+01:00 to +02:00]
Transition[Overlap at 1978-10-01T03:00+02:00 to +01:00]
Transition[Gap at 1979-04-01T02:00+01:00 to +02:00]
Transition[Overlap at 1979-09-30T03:00+02:00 to +01:00]
Transition[Gap at 1980-04-06T02:00+01:00 to +02:00]
Transition[Overlap at 1980-09-28T03:00+02:00 to +01:00]
Transition[Gap at 1981-03-29T02:00+01:00 to +02:00]
Transition[Overlap at 1981-09-27T03:00+02:00 to +01:00]
Transition[Gap at 1982-03-28T02:00+01:00 to +02:00]
Transition[Overlap at 1982-09-26T03:00+02:00 to +01:00]
Transition[Gap at 1983-03-27T02:00+01:00 to +02:00]
Transition[Overlap at 1983-09-25T03:00+02:00 to +01:00]
Transition[Gap at 1984-03-25T02:00+01:00 to +02:00]
Transition[Overlap at 1984-09-30T03:00+02:00 to +01:00]
Transition[Gap at 1985-03-31T02:00+01:00 to +02:00]
Transition[Overlap at 1985-09-29T03:00+02:00 to +01:00]
Transition[Gap at 1986-03-30T02:00+01:00 to +02:00]
Transition[Overlap at 1986-09-28T03:00+02:00 to +01:00]
Transition[Gap at 1987-03-29T02:00+01:00 to +02:00]
Transition[Overlap at 1987-09-27T03:00+02:00 to +01:00]
Transition[Gap at 1988-03-27T02:00+01:00 to +02:00]
Transition[Overlap at 1988-09-25T03:00+02:00 to +01:00]
Transition[Gap at 1989-03-26T02:00+01:00 to +02:00]
Transition[Overlap at 1989-09-24T03:00+02:00 to +01:00]
Transition[Gap at 1990-03-25T02:00+01:00 to +02:00]
Transition[Overlap at 1990-09-30T03:00+02:00 to +01:00]
Transition[Gap at 1991-03-31T02:00+01:00 to +02:00]
Transition[Overlap at 1991-09-29T03:00+02:00 to +01:00]
Transition[Gap at 1992-03-29T02:00+01:00 to +02:00]
Transition[Overlap at 1992-09-27T03:00+02:00 to +01:00]
Transition[Gap at 1993-03-28T02:00+01:00 to +02:00]
Transition[Overlap at 1993-09-26T03:00+02:00 to +01:00]
Transition[Gap at 1994-03-27T02:00+01:00 to +02:00]
Transition[Overlap at 1994-09-25T03:00+02:00 to +01:00]
Transition[Gap at 1995-03-26T02:00+01:00 to +02:00]
Transition[Overlap at 1995-09-24T03:00+02:00 to +01:00]
Transition[Gap at 1996-03-31T02:00+01:00 to +02:00]
Transition[Overlap at 1996-10-27T03:00+02:00 to +01:00]
Transition[Gap at 1997-03-30T02:00+01:00 to +02:00]
Transition[Overlap at 1997-10-26T03:00+02:00 to +01:00]
TransitionRule[Gap +01:00 to +02:00, SUNDAY on or after MARCH 25 at 02:00 STANDARD, standard offset +01:00]
TransitionRule[Overlap +02:00 to +01:00, SUNDAY on or after OCTOBER 25 at 02:00 STANDARD, standard offset +01:00]
The key here is to understand that the time-zone identifier and the "short name"of that identifier are two different elements. The identifier is always fixed as "CET", but the name changes between "CET" and "CEST".
这里的关键是要了解时区标识符和该标识符的“短名称”是两个不同的元素。标识符始终固定为“CET”，但名称在“CET”和“CEST”之间变化。
回答by akostadinov
Because you know the offset and don't want to use DTS, why not use ZoneOffset.ofHours(1)method instead of ZoneId.of("CET")?
因为你知道偏移量并且不想使用DTS，为什么不使用ZoneOffset.ofHours(1)方法而不是ZoneId.of("CET")？
Also you can call normalized()on any ZoneId instance to make it a fixed offset but sounds like less reliable than using an offset from the beginning.
您也可以调用normalized()任何 ZoneId 实例以使其成为固定偏移量，但听起来不如从头开始使用偏移量可靠。
From ZoneId javadoc:
A ZoneId is used to identify the rules used to convert between an Instant and a LocalDateTime. There are two distinct types of ID:
- Fixed offsets - a fully resolved offset from UTC/Greenwich, that uses the same offset for all local date-times
- Geographical regions - an area where a specific set of rules for finding the offset from UTC/Greenwich apply
Most fixed offsets are represented by ZoneOffset. Calling normalized() on any ZoneId will ensure that a fixed offset ID will be represented as a ZoneOffset.
ZoneId 用于标识用于在 Instant 和 LocalDateTime 之间转换的规则。有两种不同类型的 ID：
- 固定偏移量 - 从 UTC/格林威治完全解析的偏移量，对所有本地日期时间使用相同的偏移量
- 地理区域 - 应用一组特定规则来查找与 UTC/格林威治的偏移量的区域
大多数固定偏移量由 ZoneOffset 表示。对任何 ZoneId 调用 normalized() 将确保固定偏移 ID 将表示为 ZoneOffset。
If you're not using fixed offsets, then you're using geographical regions which means it depends on the region if DTS is observed or not. Same goes with PST. You'll see it observes DTS even though summer time is called PDT. Yes, it is confusing but this is how most tools work. Read the full ZoneId javadocfor a more thorough explanation (the Time-zone IDssection).
如果您不使用固定偏移量，那么您使用的是地理区域，这意味着这取决于是否观察到 DTS 的区域。PST 也是如此。即使夏令时称为 PDT，您也会看到它遵守 DTS。是的，这令人困惑，但这就是大多数工具的工作方式。阅读完整的ZoneId javadoc以获得更详尽的解释（该Time-zone IDs部分）。
