UNIX-Zeitstempel sicher konvertieren und Zeitzonen verwalten

Ein UNIX-Zeitstempel stellt einen Zeitpunkt als vergangene Zeit seit der UNIX-Epoche dar. Er speichert keine benannte Zeitzone, keine Sommerzeitregel und keine Kalenderbezeichnung. Diese Regeln werden hinzugefügt, wenn der Zeitpunkt für eine Person oder einen Ort angezeigt wird.

Schnelle Antwort: Bestimmen Sie zuerst die Einheit. Gegenwärtige zehnstellige Werte verwenden oft Sekunden. Gegenwärtige dreizehnstellige Werte verwenden oft Millisekunden. Wandeln Sie den Wert in einen Zeitpunkt um. Formatieren Sie ihn danach in UTC oder einer benannten IANA-Zeitzone. Behandeln Sie eine feste UTC-Verschiebung nie als vollständige Zeitzone.

Dieser Anwendungsfall erklärt Epochen-Einheiten, negative Werte, UTC, Offsets, saisonale Übergänge, ISO-8601-Text, JavaScript-Grenzen und Windows-Dateizeitumwandlungen. Er verbindet diese Begriffe mit dem UNIX-Zeitstempel-Konverter und der Sammlung für Datum, Uhrzeit und Zeitstempel.

Was ist ein UNIX-Zeitstempel?

Die UNIX-Epoche beginnt bei 1970-01-01 00:00:00 UTC. Ein UNIX-Zeitstempel zählt normalerweise Sekunden ohne Schaltsekunden seit diesem Referenzzeitpunkt. Positive Werte bezeichnen spätere Zeitpunkte. Negative Werte bezeichnen frühere Zeitpunkte, wenn das System sie unterstützt.

Das POSIX-Zeitmodell definiert Sekunden seit der Epoche mit Kalenderumwandlungsregeln. RFC 9636 definiert UNIX-Zeit als ganzzahlige Sekunden seit der POSIX-Epoche ohne Schaltsekunden. Implementierungen und Sprachen können engere Bereiche oder andere numerische Genauigkeit erzwingen.

Ein Zeitstempel entspricht nicht einem angezeigten Datum. Ein Zeitpunkt kann in Tokio, Kalkutta, London und New York als verschiedene lokale Daten erscheinen. Der Zeitstempel ändert sich nicht. Die Darstellung ändert sich, weil jeder Ort seine Zeitzonenregeln anwendet.

Werttyp	Beispiel	Bedeutung	Wichtigstes Risiko
UNIX-Sekunden	1725148800	Sekunden seit der Epoche	Verwechslung mit Millisekunden
UNIX-Millisekunden	1725148800000	Millisekunden seit der Epoche	Verwechslung mit Sekunden
ISO-Datum mit Z	2024-09-01T00:00:00Z	UTC-Zeitpunkt	Verlust des Z beim Parsen
ISO-Datum mit Offset	2024-09-01T05:30:00+05:30	Zeitpunkt und numerischer Offset	Offset als benannte Zone behandeln
Lokales Datum	2024-09-01 05:30	Kalenderfelder ohne eindeutigen Zeitpunkt	Zone und Überlappungswahl fehlen

Hängt ein UNIX-Zeitstempel von Zeitzonen ab?

Nein. Ein gültiger UNIX-Zeitstempel identifiziert einen Zeitpunkt unabhängig von der Anzeigezeitzone. Zeitzonen beeinflussen die Umwandlung zwischen diesem Zeitpunkt und lokalen Kalenderfeldern.

Direkte Antwort: Addieren oder subtrahieren Sie keinen lokalen UTC-Offset, um die Zeitzone eines UNIX-Werts zu „konvertieren“. Bewahren Sie den Zeitpunkt. Lassen Sie eine Zeitzonenbibliothek ihn mit der Zielzone formatieren.

Manuelle Offset-Arithmetik scheitert, wenn ein Ort seinen Offset ändert. Sommerzeit kann saisonale Änderungen erzeugen. Regierungen können zivile Regeln überarbeiten. Historische Offsets können von heutigen abweichen. Manche Regionen verwenden keine ganzzahligen Stunden-Offsets.

Die IANA-Zeitzonendatenbank zeichnet aktuelle und historische zivile Regeln für repräsentative Orte auf. Systeme aktualisieren diese Datenbank, wenn sich Regeln ändern. America/New_York enthält eine Regelhistorie. -05:00 enthält nur einen numerischen Offset.

Wie unterscheiden Sie Sekunden und Millisekunden?

Keine ziffernbasierte Regel funktioniert für jedes Datum. Die Größenordnung liefert für gegenwärtige Daten einen praktischen Hinweis. Sie ist kein formales Typsystem. Eine solide Oberfläche sollte die Einheit verlangen oder die Ableitung anzeigen.

Nahe der Gegenwart haben UNIX-Sekunden oft etwa zehn Ziffern. Millisekunden haben oft etwa dreizehn. Mikrosekunden und Nanosekunden verwenden größere Werte. Zukünftige Daten, negative Daten, führende Nullen, Dezimalwerte und Zeichenketten können einen Längentest ungültig machen.

Verwenden Sie diesen sicheren Ablauf:

1. Lesen Sie die Dokumentation des Quellsystems.
2. Bewahren Sie den Wert als Text, bis Einheit und Zahlenbereich bekannt sind.
3. Wählen Sie Sekunden, Millisekunden, Mikrosekunden oder Nanosekunden ausdrücklich.
4. Verwenden Sie bei wichtiger Genauigkeit eine Bibliothek für Ganzzahlen.
5. Vergleichen Sie das Ergebnisjahr mit dem erwarteten Geschäftsbereich.
6. Zeigen Sie die erwartete UTC- und benannte Zeitzone an.

Wenn 1725148800 ein Datum im Januar 1970 erzeugt, behandelte der Konverter wahrscheinlich Sekunden als Millisekunden. Wenn 1725148800000 ein Datum tausende Jahre entfernt erzeugt, behandelte er wahrscheinlich Millisekunden als Sekunden. Ein plausibles Jahr hilft bei der Prüfung. Die Dokumentation der Quelle bleibt maßgeblich.

Warum kann JavaScript Zeitgenauigkeit verlieren?

JavaScript Number verwendet binäre Gleitkommawerte nach IEEE 754. Es stellt Ganzzahlen nur innerhalb eines definierten sicheren Bereichs exakt dar. Millisekunden nahe aktueller Daten passen problemlos. Nanosekunden passen nicht.

ECMAScript Date speichert einen Zeitwert in Millisekunden. Die ECMAScript-Datumspezifikation definiert Wert und zulässigen Bereich. Implementierungen lehnen Werte außerhalb des Bereichs ab. Auch Parsing hängt von Eingabegrammatik und vorhandener Zone ab.

Verwenden Sie für Mikrosekunden oder Nanosekunden BigInt oder eine passende Bibliothek. Wandeln Sie eine große Ganzzahlzeichenkette nicht in Number um, bevor Sie den Bereich geprüft haben. Die Umwandlung kann untere Ziffern still runden und den Zeitpunkt ändern.

Wenn eine API Zeitstempel zurückgibt, dokumentieren Sie die Einheit im Feldnamen oder Schema. createdAtEpochSeconds ist sicherer als timestamp. JSON unterscheidet keine Ganzzahlgrößen über seine Syntax hinaus. Produzent und Konsument benötigen einen Vertrag.

Was unterscheidet UTC, Offsets und benannte Zonen?

UTC ist der gemeinsame Zeitstandard für globale Zeitpunkte. Ein UTC-Offset gibt den Unterschied zwischen lokaler Zeit und UTC zu einem Zeitpunkt an. Eine benannte Zone liefert Regeln, die den Offset nach Datum bestimmen.

Begriff	Beispiel	Ändert sich nach Datum	Identifiziert allein einen Zeitpunkt
UTC-Marker	Z	Nein	Ja, mit Datum und Uhrzeit
Numerischer Offset	+05:30	Der Wert nicht	Ja, mit Datum und Uhrzeit
IANA-Zone	Asia/Kolkata	Kann sich ändern	Nein, ohne lokales Datum und Uhrzeit
Lokale Wanduhrzeit	2026-11-01 01:30	Nicht zutreffend	Nein

Eine benannte Zone kann eine lokale Zeit während einer Rückstellung zwei Zeitpunkten zuordnen. Bei einer Vorstellung kann sie keine Zuordnung haben. Bibliotheken nennen diese Fälle Überlappungen und Lücken. Eine Anwendung benötigt eine Regel zur Auflösung.

Für geplante Ereignisse speichern Sie die beabsichtigte Semantik. Ein einmaliges Treffen kann Zeitpunkt und Anzeigezone speichern. Ein wiederkehrender Termin um 09:00 kann lokale Zeit, benannte Zone, Wiederholungsregel und Verhalten bei Datenbankänderungen benötigen. Nur den ersten Zeitpunkt zu speichern kann zukünftige Termine verschieben.

Was geschieht bei Sommerzeitübergängen?

Bei einer Frühjahrsumstellung können Uhren vorspringen. Ein lokales Intervall kann nicht existieren. Bei einer Herbstumstellung können sie zurückspringen. Ein lokales Intervall kann mit verschiedenen Offsets zweimal auftreten.

Angenommen, eine lokale Uhr zeigt 01:30 zweimal. Eine Zeichenkette nur mit lokalem Datum und Uhrzeit identifiziert nicht, welchen Zeitpunkt die Person meinte. Fügen Sie den numerischen Offset hinzu oder wenden Sie mit einer Bibliothek für benannte Zonen eine ausdrückliche Vorher- oder Nachher-Regel an.

Der ECMAScript-Entwurf Temporal modelliert diese Unterschiede. Die ZonedDateTime-Dokumentation erklärt genaue Zeit, Zone und Kalender. Sie beschreibt auch das Auflösungsverhalten für Lücken und Überlappungen. Prüfen Sie Unterstützung und Produktionsstatus, bevor Sie von einer vorgeschlagenen Schnittstelle abhängen.

Speichern Sie Zonen-Offsets nicht unbegrenzt im Cache. Aktualisieren Sie die Umgebung oder Datenbank, die IANA-Daten liefert. Halten Sie Server, Client, Container und Datenbank-Images aktuell. Veraltete Daten können zwei Dienste für dasselbe zukünftige Ereignis verschiedene lokale Zeiten berechnen lassen.

Wie sollten Sie einen Zeitpunkt formatieren?

Verwenden Sie ein maschinenlesbares Format mit einem ausdrücklichen UTC-Marker oder Offset. RFC 3339 definiert ein häufig verwendetes Datum-Zeit-Profil im Internet. Die RFC-3339-Spezifikation definiert vollständiges Datum, vollständige Uhrzeit, Offsets und optionale Bruchteile.

Beispiele:

• 2026-09-01T12:00:00Z bezeichnet Mittag UTC.
• 2026-09-01T17:30:00+05:30 bezeichnet denselben Zeitpunkt mit Offset.
• 2026-09-01T12:00:00.123Z fügt Millisekundengenauigkeit hinzu.
• 2026-09-01 12:00:00 erklärt keine Zone und keinen Offset.

Verwenden Sie T und Z in Großschreibung, wenn Interoperabilität wichtig ist. Bewahren Sie erforderliche Bruchteilsgenauigkeit. Fügen Sie keine bedeutungslosen Ziffern hinzu. Ein Ursprung mit Sekundengenauigkeit erhält keine Nanosekundengenauigkeit durch neun Nullen.

Für neue Protokolle mit benannter Zone prüfen Sie das erweiterte Format von RFC 9557. Es fügt Angaben in eckigen Klammern zu RFC-3339-Zeitstempeln hinzu, einschließlich Zonennamen. Bestätigen Sie die Unterstützung aller Konsumenten vor der Einführung.

Wie beeinflussen Schaltsekunden UNIX-Zeit?

UTC enthält gelegentlich Schaltsekunden. Übliche UNIX- und POSIX-Darstellungen ordnen nicht jedem Schaltsekunden-Label über eine einfache stetige Zuordnung einen eindeutigen normalen Zeitstempel zu. Systeme können das Ereignis ignorieren, wiederholen, glätten oder mit speziellen Uhren behandeln.

Das IANA-tz-Projekt dokumentiert Entscheidungen und Grenzen in seiner theoretischen Zeitzonen-Datei. Zeitbibliotheken zielen meist auf zivile Zeitstempel und nicht auf wissenschaftliche Hochpräzisionsmessungen.

Wenn die Anwendung Finanzsequenzen, Satellitendaten, verteilte Protokolle oder wissenschaftliche Messungen verarbeitet, definieren Sie die Zeitskala. UTC, TAI, GPS-Zeit, monotone Uhren und Systemuhren lösen verschiedene Probleme. Ein Browser-Konverter darf nicht die Autorität für Präzisionszeit sein.

Verwenden Sie eine monotone Uhr, um Dauern innerhalb eines Prozesses zu messen. Die zivile Uhr kann sich durch Synchronisierung, Verwaltung oder virtuelle Maschinen ändern. Speichern Sie Ereigniszeitpunkte für Audits. Messen Sie Codedauer mit der monotonen Schnittstelle der Plattform.

Wie konvertieren Sie einen UNIX-Zeitstempel sicher?

Folgen Sie diesem Ablauf:

1. Identifizieren Sie Quellsystem und Einheit.
2. Bewahren Sie den Originalwert für Audit und Diagnose auf.
3. Validieren Sie Syntax, Vorzeichen, Bereich und erlaubte Genauigkeit.
4. Wandeln Sie den Wert in einen Zeitpunkt um, ohne manuell einen lokalen Offset anzuwenden.
5. Formatieren Sie den Zeitpunkt als stabile Referenz in UTC.
6. Formatieren Sie denselben Zeitpunkt in der angeforderten IANA-Zone.
7. Zeigen Sie den für dieses Datum verwendeten numerischen Offset.
8. Vergleichen Sie Jahr und lokalen Kontext mit dem erwarteten Wert.

Der UNIX-Zeitstempel-Konverter bietet einen gezielten Konvertierungsablauf. Beginnen Sie mit Beispieldaten. Ein Browser-Tool hilft bei der Prüfung eines Werts. Der Vertrag der Quell-API entscheidet über die richtige Einheit.

Für Massen- oder Produktionskonvertierungen verwenden Sie eine gepflegte Bibliothek. Fixieren und aktualisieren Sie ihre Zonendaten. Fügen Sie Tests für Lücken und Überlappungen, Jahreswechsel, negative Werte, Bruchteile und den maximal erlaubten Wert hinzu.

Was unterscheidet Windows-Dateizeiten?

Windows-Dateizeit und UNIX-Zeit verwenden verschiedene Epochen und Einheiten. Ein FILETIME zählt normalerweise 100-Nanosekunden-Intervalle seit 1601-01-01 UTC. UNIX-Zeit zählt normalerweise Sekunden seit 1970-01-01 UTC.

Die Konvertierung benötigt einen Epochenoffset und einen Einheitenfaktor. Große Ganzzahlarithmetik ist wichtig, weil FILETIME den sicheren JavaScript-Bereich überschreiten kann. Eine Umwandlung über Number kann die letzten Ziffern verlieren.

Verwenden Sie das Tool UNIX zu Windows-Dateizeit für eine kontrollierte Umwandlung. Verwenden Sie das Tool Windows-Dateizeit zu UNIX für die Gegenrichtung. Bewahren Sie die ursprüngliche Ganzzahl als Text. Prüfen Sie das Ergebnis mit einer anderen Implementierung, wenn forensische Genauigkeit wichtig ist.

Die Windows-Dokumentation zu Dateizeiten beschreibt 100-Nanosekunden-Intervalle. Dateisysteme können unterschiedliche Auflösung, Aktualisierung oder lokale Konvertierung verwenden. Die nominale Einheit beweist nicht, dass die Quelle mit dieser Genauigkeit gemessen hat.

Empfehlungen für Datenbanken und APIs

Verwenden Sie einen Typ, der zum Modell passt. Ein Datenbankzeitstempel mit Zone kann einen Zeitpunkt normalisieren, aber jeder Anbieter hat eigene Semantik. Ein Zeitstempel ohne Zone kann lokale Felder darstellen. Lesen Sie die Dokumentation vor dem Entwurf einer Migration.

Für API-Ereignisse senden Sie eine RFC-3339-Zeichenkette mit Z oder eine dokumentierte Ganzzahl mit ausdrücklicher Einheit. Vermeiden Sie undokumentierte Werte. Übermitteln Sie eine benannte Zone getrennt, wenn sie geschäftliche Bedeutung hat.

Für zukünftige Termine speichern Sie mehr als einen Zeitpunkt, wenn die lokale Uhrzeit stabil bleiben muss. Ein nützlicher Datensatz kann enthalten:

• lokale Datums- und Uhrzeit;
• IANA-Zonenkennung;
• Wiederholungsregel;
• Auflösungsentscheidung;
• ursprüngliche Benutzereingabe;
• nächsten berechneten Zeitpunkt;
• Richtlinie zur Regelaktualisierung.

Für vergangene Ereignisprotokolle speichern Sie den Zeitpunkt und nützlichen Kontext. Der Offset hilft bei Anzeige und Diagnose. Die benannte Zone kann für menschliche Interpretation wichtig bleiben.

Häufige Fehler bei Zeitstempeln

Fehler 1: Einheit nur aus Ziffern erraten

Die Ziffernanzahl ist ein Hinweis. Sie ist kein Vertrag. Bestätigen Sie Quelleinheit und erwarteten Bereich.

Fehler 2: Offset addieren, um die Zone zu ändern

Diese Aktion ändert den Zeitpunkt. Bewahren Sie den Zeitpunkt und formatieren Sie ihn in der Zielzone.

Fehler 3: Abkürzung als Zone verwenden

Abkürzungen wie CST können mehrere Orte oder Offsets bezeichnen. Verwenden Sie eine IANA-Kennung oder einen dokumentierten numerischen Offset.

Fehler 4: Datum und Uhrzeit ohne Zone parsen

Ein Parser kann Gerätezone, UTC oder eine andere Regel annehmen. Verlangen Sie für Zeitpunkte einen ausdrücklichen Offset. Modellieren Sie lokale Planung mit einer benannten Zone.

Fehler 5: Saisonale Lücken und Überlappungen ignorieren

Manche lokalen Uhrzeiten existieren nicht oder treten zweimal auf. Fügen Sie Testfälle und eine Auflösungsregel hinzu.

Fehler 6: Große Zeitstempel mit Gleitkomma umwandeln

Ganzzahlen für Mikrosekunden, Nanosekunden und FILETIME können Genauigkeit verlieren. Bewahren Sie sie als Zeichenketten oder Ganzzahlen beliebiger Genauigkeit.

Fehler 7: Client-Uhr für Sicherheit verwenden

Geräteuhren können falsch oder manipuliert sein. Sicherheitsprotokolle benötigen Serverprüfung, Ablauf-Toleranz, Replay-Schutz und eine zuverlässige Zeitquelle.

Prüfliste

Beantworten Sie vor der Annahme einer Konvertierung diese Fragen:

Prüfung	Grund
Welche Einheit verwendet die Quelle?	Ein Faktorfehler von 1.000 erzeugt ein falsches Datum
Ist die Eingabe eine Ganzzahl oder Dezimalzahl?	Bruchteile können Genauigkeit ändern
Kann der Wert negativ sein?	Manche Systeme lehnen Daten vor der Epoche ab
Bewahrt der Zahlentyp den Wert?	Rundung kann untere Einheiten ändern
Verwendet die Ausgabe UTC oder eine benannte Zone?	Lokale Bezeichnungen benötigen Regeln
Kommt die lokale Uhrzeit einmal vor?	Saisonale Zeit erzeugt Lücken und Überlappungen
Welche Datenbankversion wird angewandt?	Zukünftige zivile Regeln können sich ändern
Welche Genauigkeit hat die Quelle gemessen?	Gespeicherte Ziffern können Genauigkeit übertreiben

Diese Liste macht eine mehrdeutige Zahl zu einer dokumentierten Konvertierung. Sie verbessert auch Fehlerberichte. Fügen Sie Originalwert, Einheit, erwarteten Zeitpunkt, Zielzone, Umgebung und Zonendatenversion ein.

Häufige Fragen

Verwendet UNIX-Zeit immer Sekunden?

Die traditionelle Darstellung verwendet Sekunden. Viele APIs verwenden Millisekunden, Mikrosekunden oder Nanosekunden und nennen das Feld UNIX-Zeit. Lesen Sie Schema und Einheit.

Enthält UNIX-Zeit eine Zeitzone?

Nein. Sie identifiziert einen Zeitpunkt relativ zur Epoche. Eine benannte Zone wird beim Erzeugen lokaler Kalenderfelder angewandt.

Welche Zeitzone hat 0?

Der UNIX-Wert 0 entspricht im üblichen Modell 1970-01-01 00:00:00 UTC. Lokale Ansichten können ein anderes Datum oder eine andere Uhrzeit zeigen.

Warum zeigt mein Konverter 1970?

Die häufigste Ursache ist eine falsche Einheit. Ein als Millisekunden behandelter Sekundenwert bleibt nahe der Epoche. Bestätigen Sie die Einheit.

Warum unterscheiden sich zwei Konverter um eine Stunde?

Sie können andere Zonen, saisonale Regeln, Datenbankversionen oder Mehrdeutigkeitsregeln verwenden. Vergleichen Sie UTC-Ausgaben und benannte Zonen.

Entspricht UTC GMT?

Für alltägliche Offset-Anzeigen sind sie oft austauschbar. Sie haben unterschiedliche technische Geschichten. Verwenden Sie UTC für ausdrückliche Protokolle und Standards.

Kann ich für wiederkehrende Treffen nur einen UTC-Zeitstempel speichern?

Nein, wenn das Treffen eine lokale Uhrzeit behalten muss. Speichern Sie benannte Zone und Wiederholungssemantik. Berechnen Sie zukünftige Zeitpunkte mit aktuellen Regeln.

Soll ich ISO 8601 oder UNIX-Zeit verwenden?

Verwenden Sie die passende Darstellung für die Schnittstelle. RFC-3339-Text ist lesbar und enthält einen Offset. Ganzzahlen sind kompakt, benötigen aber eine dokumentierte Einheit. Beide können denselben Zeitpunkt darstellen.

Abschließende Umwandlungsregel

Ein UNIX-Zeitstempel identifiziert einen Zeitpunkt. Eine Zeitzone erklärt, wie dieser Zeitpunkt auf einer lokalen Uhr erscheint. Halten Sie diese Begriffe getrennt.

Bestätigen Sie die Einheit vor der Umwandlung. Bewahren Sie Ganzzahlgenauigkeit. Zeigen Sie UTC als stabile Referenz. Verwenden Sie eine IANA-Zone für die lokale Ausgabe. Testen Sie saisonale Grenzen und historische Daten. Diese Schritte verhindern die meisten Fehler vor Produktionsdaten.