❌ Die akzeptierte Antwort ist weder richtig noch sinnvoll.
✅ Die Antwort von Ole V.V. fasst dagegen die technischen Unterschiede korrekt zusammen – für Details folgen Sie den Links zu den ausführlichen Seiten in Wikipedia.
Für Programmierer, die geschäftsorientierte Anwendungen bauen, ist das Fazit, dass UTC die neue GMT ist. Sie können die Begriffe austauschbar verwenden, wobei der Unterschied buchstäblich weniger als eine Sekunde beträgt. Für alle praktischen Zwecke in den meisten Anwendungen gibt es also überhaupt keinen Unterschied.
Hier ein paar weitere praktische Ratschläge, mit Code-Beispielen.
Strings
Angenommen, ich habe die UTC-Zeit als „02-01-2018 00:03“, bedeutet das, dass meine US-Lokalzeit „01-01-2018 18:00“ ist?
Der erste Teil ist ein schlechtes Beispiel, da dem Datum-Zeit-String ein Indikator für seinen Offset oder seine Zone fehlt.
Wenn eine Zeichenkette einen bestimmten Zeitpunkt angibt, muss sie entweder eine Zeitzone (Continent/Region formatierter Name) und/oder einen Offset-from-UTC als Anzahl von Stunden-Minuten-Sekunden angeben. Wenn die Zeichenkette einen Moment in UTC selbst darstellen soll, bedeutet das einen Offset-from-UTC von Null.
Um diese Zeichenkette mit einem Offset zu schreiben, können verschiedene Konventionen angewendet werden. In der Praxis ist es am besten, sowohl Stunden als auch Minuten zusammen mit einem Doppelpunkt zu schreiben, zum Beispiel +00:00+05:30 oder -08:00. Die führende Null und der Doppelpunkt sind beide optional, aber ich habe gesehen, dass Bibliotheken abbrechen, wenn sie auf einen Wert wie -0800 oder -8 treffen.
Zulu
Als Abkürzung für einen Offset von Null wird der Buchstabe Z häufig für UTC selbst verwendet. Ausgesprochen Zulu.
ISO 8601
Für die textuelle Formatierung von Datums- und Zeitangaben für die Datenverarbeitung werden am besten die Standardformate der ISO 8601 verwendet. Für eine Datumszeit wird das Format JJJJ-MM-TTTHH:MM:SS±HHH:MM:SS verwendet. Das T trennt den Datumsteil vom Uhrzeitteil. Dieses Format hat den Vorteil, dass es weitgehend eindeutig ist, maschinell leicht zu parsen und von Menschen kulturübergreifend leicht zu lesen ist. Ein weiterer Vorteil ist, dass die alphabetische Sortierung auch chronologisch ist. Der Standard akzeptiert auch die Z-Abkürzung.
So wird Ihr Beispiel UTC time as "02-01-2018 00:03" besser als 2018-01-02T00:03Z angegeben.
java.time
Seien Sie sich darüber im Klaren, dass die meisten Programmiersprachen, Bibliotheken und Datenbanken eine sehr schlechte Unterstützung für die Behandlung von Datums- und Zeitangaben haben, die in der Regel auf einem schlechten Verständnis der Datums- und Zeitproblematik beruht. Der Umgang mit der Datumszeit ist überraschend kompliziert und schwierig zu beherrschen.
Die einzige anständige Bibliothek, auf die ich gestoßen bin, sind die java.time-Klassen (siehe Tutorial), die mit Java 8 und höher mitgeliefert werden, und ihr Vorgänger, das Joda-Time-Projekt (das auch lose von Java nach .Net im Noda-Time-Projekt portiert wurde).
In java.time wird ein Moment auf drei Arten dargestellt. Alle haben eine Auflösung von Nanosekunden.
-
Instant
Immer in UTC. Technisch gesehen, eine Zählung von Nanosekunden seit der Epochenreferenz des ersten Moments von 1970 (1970-01-01T00:00:00Z). -
OffsetDateTime
Ein Datum mit Tageszeit im Kontext einer bestimmten Anzahl von Stunden-Minuten-Sekunden vor oder hinter UTC. -
ZonedDateTime
Ein Datum mit Uhrzeit im Kontext einer bestimmten Zeitzone.
Was ist also der Unterschied zwischen einer Zeitzone und einem Offset-from-UTC? Warum brauchen wir getrennte Klassen? Ein Offset-from-UTC ist einfach eine Anzahl von Stunden-Minuten-Sekunden, drei Zahlen, nicht mehr und nicht weniger. Eine Zeitzone ist viel mehr. Eine Zeitzone ist eine Geschichte der vergangenen, gegenwärtigen und zukünftigen Änderungen der Zeitverschiebung, die von den Menschen in einer bestimmten Region verwendet wird.
Welche Änderungen? Änderungen, die von den Launen oder der Weisheit ihrer Politiker diktiert werden. Politiker auf der ganzen Welt haben eine Vorliebe für die Änderung der Zeitverschiebung der Zeitzone(n) in ihrem Zuständigkeitsbereich gezeigt. Die Sommerzeit (DST) ist ein häufiges Muster von Änderungen, wobei ihr Zeitplan oft geändert wird und die Entscheidung, die Sommerzeit einzuführen oder wieder rückgängig zu machen, manchmal geändert wird. Andere Änderungen kommen auch vor, wie z.B. Nordkorea, das gerade in den letzten Jahren seine Uhr um eine halbe Stunde umstellte, um sich mit Südkorea zu synchronisieren, Venezuela, das seine Uhr um eine halbe Stunde zurückdrehte, nur um weniger als ein Jahrzehnt später wieder nach vorne zu springen, die Türkei, die dieses Jahr die geplante Umstellung von Sommerzeit auf Standardzeit mit wenig Vorwarnung absagte, und das heutige Russland, das in den letzten Jahren mehrere solcher Änderungen vornahm.
Zurück zu Ihrem Beispiel in Punkt # 3, lassen Sie uns einen Blick auf den Code werfen.
Sagen wir, ich habe die UTC-Zeit als „02-01-2018 00:03“, bedeutet das, dass meine US-Lokalzeit „01-01-2018 18:00“ ist?
Ihre Beispielstrings haben ein weiteres Problem. Die 03 Minute im ersten Teil wird in Ihrem zweiten Teil ignoriert, ein offensichtlicher Tippfehler. Ich weiß das, weil an diesem Datum in Amerika keine Zeitzonenanpassung in Kraft ist, die einen Stundenbruchteil von 57 Minuten beinhaltet.
Nicht einen Moment
Zunächst analysieren wir Ihre Eingabezeichenfolge. In Ermangelung eines Indikators für die Zone oder den Versatz müssen wir mit dem LocalDateTime parsen. Der Name LocalDateTime kann irreführend sein, da er eine bestimmte Örtlichkeit meint. Es bedeutet eine oder alle Örtlichkeiten. Weitere Erklärungen finden Sie unter Was ist der Unterschied zwischen Instant und LocalDateTime?
String input = "2018-01-02T00:03" ; // Text of a date with time-of-day but without any context of time zore or offset-from-UTC. *Not* a moment, *not* a point on the timeline.LocalDateTime ldt = LocalDateTime.parse( input ) ; // Parsing the input as a `LocalDateTime`, a class representing a date with time but no zone/offset. Again, this does *not* represent a moment, is *not* a point on the timeline. UTC
Durch die in der Frage genannten Fakten wissen wir, dass dieses Datum und diese Uhrzeit einen Moment in UTC darstellen sollen. Wir können also den Kontext eines Offsets-from-UTC von null Stunden-Minuten-Sekunden für UTC selbst zuordnen. Wir wenden eine ZoneOffset Konstante UTC an, um ein OffsetDateTime Objekt zu erhalten.
OffsetDateTime odt = ldt.atOffset( ZoneOffset.UTC ); // We are certain this text was intended to represent a moment in UTC. So correct the faulty text input by assigning the context of an offset of zero, for UTC itself.Zeitzone
Die Frage verlangt, diesen Moment durch eine Wanduhrzeit zu sehen, die sechs Stunden hinter der in den Vereinigten Staaten verwendeten UTC liegt. Eine Zeitzone mit einem solchen Versatz ist America/Chicago.
Geben Sie einen korrekten Zeitzonennamen im Format continent/region an, wie zum Beispiel America/MontrealAfrica/Casablanca oder Pacific/Auckland. Verwenden Sie niemals die 2-4-Buchstaben-Kürzel wie CSTEST oder IST, da diese keine echten Zeitzonen sind, nicht standardisiert und nicht einmal eindeutig(!).
ZoneId z = ZoneId.of( "America/Chicago" ) ; // Adjust from UTC to a time zone where the wall-clock time is six hours behind UTC.ZonedDateTime zdt = odt.atZoneSameInstant( z ) ;Sehen Sie diesen Code live bei IdeOne.com.
odt.toString(): 2018-01-02T00:03Z
zdt.toString(): 2018-01-01T18:03-06:00
Gleicher Moment, unterschiedliche Wanduhrzeit
Dieses odt und zdt stellen beide denselben gleichzeitigen Moment dar, denselben Punkt auf der Zeitachse. Der einzige Unterschied ist die Wanduhrzeit.
Lassen Sie uns ein Beispiel mit Island arbeiten, dessen Zeitzone einen Offset-von-UTC von null Stunden-Minuten-Sekunden verwendet. Die Zone Atlantic/Reykjavik hat also eine mit der UTC identische Wanduhrzeit. Zumindest heute stimmt ihre Wanduhrzeit mit UTC überein; in der Vergangenheit oder Zukunft kann sie anders sein, weshalb es nicht korrekt ist, zu sagen „UTC ist die Zeitzone von Island“. Wie auch immer, unser Beispiel… sagen wir, jemand in Reykjavík, Island mit 3 Minuten nach Mitternacht auf der Uhr an der Wand tätigt einen Telefonanruf an jemanden in den USA. Diese US-Person lebt an einem Ort, der die Zeitzone der Region Chicago nutzt. Als der Angerufene den Hörer abnimmt, schaut er auf die Wanduhr und sieht, dass es kurz nach 18 Uhr (18:03) ist. Gleicher Moment, andere Wanduhrzeit.
Auch die Kalender, die an ihren Wänden hängen, sind unterschiedlich, denn in Island ist es „morgen“, aber auf dem amerikanischen Festland „gestern“. Gleicher Moment, unterschiedliche Daten!
Über java.time
Das java.time-Framework ist in Java 8 und höher eingebaut. Diese Klassen ersetzen die lästigen alten Legacy-Datum-Zeit-Klassen wie java.util.DateCalendar&SimpleDateFormat.
Das Joda-Time-Projekt, das sich derzeit im Wartungsmodus befindet, rät zur Migration auf die java.time-Klassen.
Weitere Informationen finden Sie im Oracle-Tutorial. Und suchen Sie auf Stack Overflow nach vielen Beispielen und Erklärungen. Die Spezifikation ist JSR 310.
Sie können java.time-Objekte direkt mit Ihrer Datenbank austauschen. Verwenden Sie einen JDBC-Treiber, der mit JDBC 4.2 oder höher konform ist. Sie benötigen keine Strings und keine java.sql.*-Klassen.
Woher bekommt man die java.time-Klassen?
- Java SE 8, Java SE 9, Java SE 10, Java SE 11 und später – Teil der Standard-Java-API mit einer gebündelten Implementierung.
- Java 9 fügt einige kleinere Funktionen und Korrekturen hinzu.
- Java SE 6 und Java SE 7
- Der Großteil der java.time-Funktionalität wurde in Java 6 & 7 zurückportiert.
- Android
- Spätere Versionen von Android bündeln Implementierungen der java.time-Klassen.
- Für frühere Android-Versionen (<26) passt das Projekt ThreeTenABP das oben erwähnte ThreeTen-Backport an. Siehe ThreeTenABP….
Das ThreeTen-Extra-Projekt erweitert java.time um zusätzliche Klassen. Dieses Projekt ist ein Versuchsfeld für mögliche zukünftige Erweiterungen von java.time. Vielleicht finden Sie hier einige nützliche Klassen wie IntervalYearWeekYearQuarter, und mehr.