Java.heure: Le fuseau horaire CET prend-il en compte l'heure d'été?
J'utilise la nouvelle implémentation java.timede Java 8 une interrogation sur la sortie d'un UTC en CET résultat de conversion temporelle.
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);
Je m'attendais à ce que l'heure CET soit toujours + 1 de l'heure UTC mais à la place j'ai eu:
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
Donc apparemment, je dois faire face à l'heure d'été à laquelle je ne m'attendais pas lors de l'utilisation de CET. Le java.time CET est-il en vérité CEST ? Et si oui, quelle zone dois-je utiliser si j'ai besoin de CET?
2 answers
La définition IANA de CET est qu'il suit les règles de fuseau horaire de l'Europe centrale, qui comprend à la fois l'heure d'hiver et l'heure d'été. Les règles peuvent être vues ici, ce qui montre que "CET" est basé sur "C-Eur" qui inclut l'heure d'été.
Dans java.time vous pouvez également voir l'ensemble complet de règles:
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);
}
, Qui imprime:
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]
La clé ici est de comprendre que l'identifiant de fuseau horaire et le "nom court" {[5] } de cet identifiant sont deux les différents éléments. L'identifiant est toujours fixé comme "CET", mais le nom change entre" CET "et"CEST".
Parce que vous connaissez le décalage et que vous ne voulez pas utiliser DTS, pourquoi ne pas utiliser la méthode ZoneOffset.ofHours(1) au lieu de ZoneId.of("CET")?
Vous pouvez également appeler normalized() sur n'importe quelle instance ZoneId pour en faire un décalage fixe, mais cela semble moins fiable que d'utiliser un décalage depuis le début.
À Partir de ZoneId javadoc:
Un ZoneId est utilisé pour identifier les règles utilisées pour convertir entre une Instantanée et un LocalDateTime. Il existe deux types distincts d'ID:
- Fixe offsets - un décalage entièrement résolu par rapport à UTC / Greenwich, qui utilise le même décalage pour toutes les dates-heures locales
- Régions géographiques - une zone où un ensemble spécifique de règles pour trouver le décalage de UTC/Greenwich s'applique
La plupart des décalages fixes sont représentés par ZoneOffset. Appel normalisé() sur n'importe quel ZoneId garantira qu'un ID de décalage fixe sera représenté en tant que ZoneOffset.
Si vous n'utilisez pas de compensations fixes, alors vous utilisez géographique régions ce qui signifie que cela dépend de la région si DTS est observé ou non. Même chose avec PST. Vous verrez qu'il observe DTS même si l'heure d'été est appelée PDT. Oui, c'est déroutant, mais c'est ainsi que la plupart des outils fonctionnent. Lisez le ZoneId javadoc complet pour une explication plus approfondie (la section Time-zone IDs).