java.Zeit: Hat die MEZ-zone ist der Auffassung Sommerzeit?

Ich das neue java.time Implementierung von Java 8, und wundere mich über die Ausgabe von UTC zu MEZ Zeit umrechnungsergebnis.

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);

Ich erwartet, dass die CET-Zeit würde immer +1 von der UTC-Zeit, aber stattdessen bekam ich:

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

Also anscheinend ich haben, um mit der Sommerzeit, die ich nicht erwarten, dass bei der Verwendung von MEZ. Ist die java.time MEZ in Wahrheit CEST? Und wenn ja, welche zone sollte ich verwenden, wenn ich brauche MEZ?

  • CET ist nicht identisch mit UTC+1 wenigstens, wie die IANA time zone database definiert. Und das ist, was Java -, POSIX-und mehrere Datenbank-Anbieter verwenden.
  • Ihr Kommentar 'CET ist nicht identisch mit UTC+1' zu sein scheint, der die meisten richtigen Antworten - obwohl die wiki Referenz-Dokumente einen festen UTC-offset von +1 (+2 MESZ in Regionen mit Sommerzeit). Ich habe einen kurzen Blick auf die IANA aber das hat nicht geholfen, mich zu verstehen, seine definition. Dennoch, wenn Sie fügen Sie Ihren Kommentar als Antwort (vielleicht einige mehr hintergrund-Informationen) ich würde es akzeptieren.
InformationsquelleAutor FrVaBe | 2014-11-12
  1. 22

    Den IANA definition von MEZ ist, dass es folgt das Zeit-zone die Regeln der zentralen Europa, die sowohl winter-und Sommer-Zeit. Die Regeln gesehen werden kann hier, die zeigt, dass "MEZ" basiert auf "C-Eur" umfasst Sommer-Zeit.

    In java.time Sie können auch sehen, das vollständige Regelwerk:

    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);
}

    ausgegeben:

    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]

    Der Schlüssel hier ist, um zu verstehen, dass die time-zone-id und die "kurzer name" der Kennung sind zwei verschiedene Elemente. Der identifier ist immer behoben, da "CET", aber der name ändert sich zwischen "CET" und "CEST".

    • Immer noch verwirrend für mich, es ist schon irgendwie anders als die übliche Erklärung von MEZ, die gefunden werden können, die außerhalb der IANA (z.B. wikipedia), aber sicherlich die beste - und richtige - Antwort. Danke.
    InformationsquelleAutor JodaStephen
  2. 1

    Weil Sie wissen, das offset und möchten nicht mit DTS, warum nicht ZoneOffset.ofHours(1) Methode statt ZoneId.of("CET")?

    Auch Sie können call normalized() auf jedem amp; zoneid Instanz zu machen, einen festen offset aber klingt weniger zuverlässig als mit einem offset von Anfang an.

    Vom Amp; zoneid javadoc:

    Einem amp; zoneid wird benutzt, um die Regeln zum konvertieren zwischen einem
    Sofortige und LocalDateTime. Es gibt zwei verschiedene Arten von ID:

    • Festen offsets - ein vollständig gelöst offset von UTC/Greenwich, mit dem gleichen offset für alle lokalen Datum-Zeiten
    • Geographische Regionen - ein Bereich, wo ein bestimmter Satz von Regeln für die Suche nach der offset von UTC/Greenwich gelten

    Meisten festen offsets sind vertreten durch ZoneOffset. Aufruf normalisiert()
    auf jedem amp; zoneid wird sichergestellt, dass ein fester offset-ID dargestellt werden
    als ZoneOffset.

    Wenn du nicht mit festen offsets, dann sind Sie mit den geografischen Regionen, was bedeutet, es hängt von der region, wenn DTS-beobachtet wird oder nicht. Gleiche geht auch mit PST. Du wirst sehen, es beobachtet DTS wenn der Sommer auch die Zeit als PDT bezeichnet. Ja, es ist verwirrend, aber dies ist, wie die meisten tools arbeiten. Lesen Sie den vollständigen Amp; zoneid javadoc für eine ausführliche Erklärung (der Time-zone IDs Abschnitt).

    • Ich brauche zum Lesen eine date-Wert aus einer Datenbank, die halte ich für in MEZ. Ich dachte, über die Zeitzone und die entsprechenden Regeln behandeln würde, offsets und Sommerzeit (falls relevant) für mich.
    • es sollten damit umgehen. Lesen Sie timeanddate.com/time/zones/cet . Sie werden sehen, dass die zone umfasst Regionen, die Beobachter DTS. Es gibt Regionen mit gleichen Zeitzone, aber ohne DTS, was geschrieben ist als +1. Denkst du, das system speichern Sie die Werte auf die DB ist MEZ für Bereiche, die sind wirklich +1? btw, das ist einer der Gründe warum immer speichern UTC DB. Das andere ist, dass in Zeiten, lokale Zeit, mit DTS nicht eindeutig zu UTC konvertiert.
    • Ich dachte nur - wie bereits in dem link, den Sie - MEZ ist immer UTC+1, es wäre ja sonst MESZ. In diesem Fall MEZ wäre so gut wie UTC. Konvertierung zwischen den beiden wäre einfach, aber jetzt habe ich beobachtet, dass DST Angelegenheiten in MEZ und ich Frage mich, warum. Meine einfache Frage wäre: Warum ist MEZ nicht immer UTC+1 bei der Verwendung von java.Zeit?
    • aktualisiert meine Antwort. Im Grunde glaube ich, was Sie Fragen können sein gefunden in amp; zoneid javadoc. d.h. die geographische region vs Feste Zeitzone.
    • Sie können nicht normalized() für diese Aufgabe. normalized() wird eine offset-basierte ZoneID falls die ZoneID auf, die Sie nennen, es hat einen festen offset als gut, da sonst die ZoneID ist unverändert zurückgegeben. Oder in anderen Worten, die zugrunde liegenden ZoneRules und damit das Gesamtergebnis zu dieser Frage nicht ändern, wenn mit einem normalized() ZoneID.
    • danke!

    InformationsquelleAutor akostadinov
Schreibe einen Kommentar