Unix-Zeitstempelkonverter: Epochen, Zeitzonen und der Bug Year-57123

Ein Benutzer einer meiner Laravel-SaaS-Apps, die einmal per E-Mail an die Angabe seines Abonnements für die Verlängerung des Abonnements sagte, sah "etwas großzügig aus". Die Abrechnungsseite teilte ihm mit, dass sein Plan am 25. April des Jahres verlängert werden würde 57123drohen

Der Fehler brauchte peinlich lange, weil ich jedes einzelne Stück richtig war. Das React-Frontend wurde gesendet Date.now() - Welches kehrt zurück Millisekunden - und das PHP-Backend hat es getan date('Y-m-d', $timestamp), das erwartet Sekundedrohen zuführen 1740470400000 in eine Funktion erwarten 1740470400 Und Sie landen in der Zukunft rund 55.000 Jahre. Keine Ausnahme, keine Warnung, kein fehlgeschlagener Test. Nur ein Kunde fragt höflich, ob sein Abonnement wirklich bis zum Tod der Zivilisation gedauert hat.

Zeitstempel sehen aus wie das langweiligste Thema in der Software. Sie sind tatsächlich eine der zuverlässigsten Bugfactories, die wir haben: Sekunden gegenüber Millisekunden, UTC gegenüber lokalen, DST-Übergängen, der Rollover 2038. der Zeitstempelkonverter Auf toolz.dev existiert, weil ich es satt hatte zu tun new Date(x * 1000) in einer Browserkonsole vierzig Mal am Tag. Dieser Leitfaden behandelt das, was ich jetzt überprüfe, in der Reihenfolge, in der ich es überprüfe.

tl; dr: Ein Unix-Zeitstempel zählt Sekunden seit 1970-01-01T00:00:00 UTC. 10 Stellen = Sekunden, 13 Ziffern = Millisekunden - Durch Vermischen Ihrer Daten 55.000 Jahre frei. UTC speichern, nur für Anzeige konvertieren, IANA-Zonennamen wie z. Asia/Dhaka statt Abkürzungen. Fügen Sie einen beliebigen Zeitstempel in die Zeitstempelkonverter Um ISO 8601, RFC 2822, Local und UTC Formulare zu erhalten – es wird clientseitig ausgeführt, also Zeitstempel aus Josefakt Und Produktionsprotokolle verlassen Ihren Browser nie.

Was genau ist ein Unix-Zeitstempel?

Ein Unix-Zeitstempel (Epoch-Zeit, POSIX-Zeit) ist die Anzahl der seit verstrichenen Sekunden 1. Januar 1970, 00:00:00 UTC - Die "UNIX-Epoche" ist eine einzelne Ganzzahl, sie hat keine Zeitzone (es ist immer UTC per Definition), und effektiv versteht jedes Betriebssystem, jede Sprache und Datenbank. Diese letzte Eigenschaft hat fünf Jahrzehnte überlebt: Es ist das einzige Zeitformat, über das niemand streitet.

Warum 1970? Kein tiefer Grund - es war ein günstiges Rundentermin in der Nähe der Zeit, als Unix bei Bell Labs gebaut wurde, und die frühe Unix-Zeit in einer 32-Bit-Ganzzahl. Die willkürliche Wahl wurde in einen universellen Standard, der sehr unix ist, versteinert.

Einige Referenzpunkte, die es wert ist, auf Sicht zu erkennen:

Diese vierte Zeile ist aus einem subtilen Grund mein Lieblingsbeispiel: Viele Tutorial-Seiten listen 1740470400 als "25.02.2025, 12:00:00.“ 08:00 UTC — Jemand hat es einmal in seiner lokalen Zeitzone umgewandelt und seitdem wurde der falsche Wert kopiert. Überprüfen Sie Zeitstempel mit einem Tool, nicht mit einem Blog-Beitrag. einschließlich dieses.

Sekunden oder Millisekunden - Wie sagen Sie das?

Zählen Sie die Ziffern. Für jedes Datum in der aktuellen Ära:

• 10 Ziffern (1740470400) - Sekunden. UNIX-Konvention, die meisten APIs, PHP time(), Python time.time() (als Float), Stripe's API.
• 13 Ziffern (1740470400000) — Millisekunden JavaScript Date.now(), Java System.currentTimeMillis(), Mongodb-Daten.

Dies ist die genaue Unterscheidung, die mein Jahr-57123-Erneuerungsdatum hervorgebracht hat. Ich werde also die Fehlermodi formulieren:

• MS interpretiert als Sekunden → Datum ~55.000 Jahre in der Zukunft
• Sekunden interpretiert als MS → Datum in Januar 1970 (Alles klappt innerhalb von ~ 3 Wochen nach der Epoche zusammen)

Wenn Sie entweder Unterschriften sehen - alte Daten oder absurde Daten aus der Ferne -, kennen Sie den Fehler, bevor Sie eine Codezeile lesen. der Zeitstempelkonverter Erkennt die Ziffernzählung und bezeichnet beide Interpretationen, die das Argument "Ist dies oder ms" in zwei Sekunden abwickeln.

Welche Datumsformate müssen Sie eigentlich kennen?

Drei decken fast alles ab, was ein arbeitender Entwickler berührt.

ISO 8601 — Der internationale Standard und was Sie in APIs und Protokollen ausgeben sollten:

2026-07-13T09:30:45Z          UTC ("Z" = Zulu)
2026-07-13T15:30:45+06:00     with timezone offset
2026-07-13T09:30:45.123Z      with milliseconds

Das Killer-Feature, das niemand erwähnt: ISO 8601-Saiten lexikographisch in chronologischer Reihenfolge sortierendrohen sort Auf einer Protokolldatei funktioniert einfach. 02/25/2026-Stilformate können das nicht - und noch schlimmer, uns MM/DD und europä DD/MM sind nicht an jedem Monat zwölf Tage zu unterscheiden.

RFC 3339 (Spezif) — das Internet-Protokoll-Profil von ISO 8601. etwas strenger; wenn Ihre API ausstößt 2026-07-13T09:30:45Z Sie befriedigen beide. Dies ist das Format, das standardisiert werden soll.

RFC 2822 (Sun, 13 Jul 2026 09:30:45 +0000) — E-Mail- und HTTP-Header, RSS-Feeds. Du liest es öfter als du schreibst.

Datenbankformate sind enge Cousins: MySQL DATETIME ist 2026-07-13 09:30:45 (ISO mit Leerzeichen), PostgreSQL timestamptz Putz 2026-07-13 09:30:45+00drohen

Wie verwende ich die Sprachen, die ich verwende?

Die drei aus meinem eigenen Stapel - und die Eigenart in jedem, der mich persönlich Zeit gekostet hat.

Javascript (die MS)

Math.floor(Date.now() / 1000)        // current Unix seconds — Date.now() is ms!
new Date(1740470400 * 1000)          // seconds → Date: multiply by 1000
date.toISOString()                   // "2025-02-25T08:00:00.000Z"
Date.parse('2026-07-13T09:30:45Z') / 1000   // ISO string → Unix seconds

Quirk: Alles ist Millisekunden und new Date(1740470400) Stille gibt Ihnen den 21. Januar 1970 statt Februar 2025. Kein Fehler. Diese Asymmetrie ist der häufigste Zeitstempelfehler in der Webentwicklung.

PHP (die Sekunde)

time();                                   // current Unix seconds
date('Y-m-d H:i:s', 1740470400);          // "2025-02-25 08:00:00" (server TZ!)
strtotime('2026-07-13 09:30:45');         // string → timestamp
(new DateTime('@1740470400'))
    ->setTimezone(new DateTimeZone('Asia/Dhaka'))
    ->format(DateTime::ATOM);             // "2025-02-25T14:00:00+06:00"

Quirk: date() Formate in der Server Standardzeitzone, so dass der gleiche Code unterschiedliche Daten auf Ihrem Computer und in der Produktion druckt. auch, new DateTime('@1740470400') Ignoriert jede Zeitzone, die Sie an den Konstruktor übergeben @ Formular ist immer UTC; Sie müssen anrufen setTimezone() nach WordPress fügt seine eigene Ebene hinzu: current_time('timestamp') Gibt einen gefälschten "lokalen" Zeitstempelversatz von der realen Unix-Zeit zurück, der genau so gefährlich ist, wie es sich anhört.

Python:

import time, datetime
int(time.time())                                      # current Unix seconds
datetime.datetime.fromtimestamp(1740470400,
    tz=datetime.timezone.utc)                         # → aware datetime
dt.isoformat()                                        # "2025-02-25T08:00:00+00:00"

Quirk: fromtimestamp() ohne tz= Gibt eine naive DateTime in der Ortszeit zurück. Naive Datetimes sind der Python-Zeitfehler: Sie vergleichen und subtrahieren glücklich gegeneinander, bis der Tag einer von ihnen eine DST-Grenze überschritt. immer bestehen tz=; ; verwenden zoneinfo (Stdlib seit 3.9) für benannte Zonen.

Wie sollten Sie mit Zeitzonen umgehen, ohne den Verstand zu verlieren?

Vier Regeln, alle haben den nervigen Weg gelernt:

1. UTC speichern. immer. Unix-Zeitstempel oder timestamptz in der Datenbank. Die Zeitzone wird nur zu einem Anzeigeproblem.
2. Konvertieren Sie auf der Präsentationsschicht. Der Benutzer in Dhaka sieht +06:00, sieht der Nutzer in Berlin +02:00, die Datenbank sieht auch nicht.
3. Verwenden Sie IANA-Namen, keine Abkürzungen. Asia/Dhaka, America/New_York, Europe/Berlindrohen Abkürzungen sind mehrdeutig – CST Bedeutet die zentrale Zeit in den USA, in China oder in Kuba Standardzeit, je nachdem, wer liest - und Abkürzungen codieren keine DST-Regeln. Iana-Namen tun.
4. Niemals DST-Logik mit der Hand rollen. Die DST-Daten unterscheiden sich je nach Land, Änderungen nach Gesetzgebung und einige Orte (Arizona, Bangladesch, Japan) beobachten die DST überhaupt nicht. Die IANA TZ-Datenbank existiert, weil dies wirklich schwierig ist, verwenden Sie die Bibliothek, die sie umschließt.

Die Folge von Regel 1: Wenn zwei Systeme über eine Ereigniszeit nicht einverstanden sind, konvertieren Sie beide Werte in UTC UNIX-Zeitstempel und vergleichen Sie die ganzen Zahlen. Argumente über "Aber es heißt hier 15 Uhr" auflösen.

Was ist das Y2038-Problem und sollte es Sie interessieren?

Eine 32-Bit-Ganzzahl maximiert bei 2,147,483,647drohen Als Unix-Zeitstempel ist das 19. Januar 2038, 03:14:07 UTCdrohen Eine Sekunde später wird der Wert negativ - bis zum 13. Dezember 1901.

Klingt weit weg, es ist aus zwei Gründen nicht. Erstens sind es ungefähr 11,5 Jahre, während ich dies schreibe - genau in der Lebensdauer von eingebetteten Systemen, Industriesteuerungen und dem ein Vermächtnis, den niemand berühren möchte. Zweitens, Zukunft Daten frühzeitig an die Wand: Ein System, das einen 15-jährigen Hypothekenplan oder einen 20-jährigen Zertifikatsablauf berechnet 2038 heutedrohen MySQL & # 39; S. TIMESTAMP Der Spaltentyp ist die klassische Falle - sie ist 32-Bit-gebunden und kann Daten nach dem 19.01.2038 nicht speichern. DATETIME in derselben Datenbank ist in Ordnung.

Sie sind auf 64-Bit sicher time_t (jedes moderne Betriebssystem), Javascript (float64 MS), Python (willkürliche Präzision) und PostgreSQL. Sie sind auf 32-Bit-Embedded-Systemen gefährdet, alt TIMESTAMP Spalten und C-Code, der fest codiert int32_t Für die Zeit. Der Test ist einfach: Push 2147483648 (eins über das Limit hinaus) durch Ihre Pipeline und sehen, was herauskommt. der Zeitstempelkonverter Generieren Sie gerne Ihre Testwerte nach 2038.

Wo tauchen Zeitstempel im echten Debuggen auf?

JWT-Ablauf. Tokens tragen iat und exp Ansprüche als Unix-Sekunden:

{ "sub": "user_8241", "iat": 1783915890, "exp": 1783919490 }

"Warum ist dieser Benutzer abgemeldet?", Wird durch Konvertieren beantwortet expdrohen Dekodieren Sie das Token in der JWT-Decoder und konvertieren Sie den Anspruch - beide laufen clientseitig, was wichtig ist, da ein eingefügter Token ein Live-Anmeldeinformationen ist (die Datenschutz-Leitfaden Belegt, warum ich mich weigere, Token in serverseitige Tools einzugeben.

Log-Korrelation. Ein Vorfall, drei Dienste, drei Formate: Nginx-Protokolle [13/Jul/2026:09:30:45 +0000], die App protokolliert ISO 8601, ein Warteschlangenarbeiter protokolliert rohe Epochensekunden. Das Konvertieren von allem in ein Format ist der Schritt Null des Erstellens einer Zeitleiste.

API-Integration. Stripe sendet "created": 1740470400 (Sekunden). Eine von Javascript erstellte API sendet 1740470400000 (MS). Google-APIs senden RFC 3339-Strings. Wenn Sie alle drei konsumieren, ist die Konvertierung nicht gelegentlich - sie ist konstant. Formatieren Sie die Nutzlasten in der JSON-Formater und konvertieren Sie die interessanten Felder.

Datums-Range-Abfragen. WHERE created_at >= 1752364800 AND created_at < 1752451200 - Ist das der richtige Tag? Konvertieren Sie beide Grenzen und überprüfen Sie, In UTC, bevor Sie das Löschen ausführen. VERBINDUNG: Die Datumsdifferenzrechner für "Wie viele Tage zwischen diesen beiden?" Zeitzonenkonverter für die Besprechungszeit Mathematik und die Cron Parser Für "Wann feuert dieser Zeitplan tatsächlich?"

Häufig gestellte Fragen

Was ist ein Unix-Zeitstempel?

Die Anzahl der seit dem 1. Januar 1970 verstrichenen Sekunden, 00:00:00 UTC (Unix Epoche), als einzelne Ganzzahl gespeichert. Es ist per Definition zeitzonenunabhängig - der gleiche Moment ist überall auf der Erde gleich Nummer - weshalb es das Standardaustauschformat über Betriebssysteme, Sprachen und Datenbanken hinweg ist.

Warum haben einige Zeitstempels 10 Ziffern und andere 13?

10 Ziffern sind Sekunden (Standard Unix-Konvention, PHP, MOST APIs); 13-Ziffern sind Millisekunden (JavaScript) Date.now(), Java). Teilen Sie durch 1.000, um von ms in Sekunden zu gehen. Die Verwirrung der beiden Schichten stammt entweder von ~55.000 Jahren in die Zukunft oder bis auf Januar 1970 zurück.

Können Unix-Zeitstempel Daten vor 1970 darstellen?

Ja – Negative Werte zählen rückwärts aus der Epoche. -86400 ist der 31. Dezember 1969. Ein 32-Bit-Zeitstempel reicht bis zum 13. Dezember 1901 zurück. Einige Systeme und APIs lehnen jedoch negative Zeitstempel ab. Testen Sie daher, bevor Sie sich auf sie verlassen.

Was ist das Y2038-Problem?

32-Bit-Zeitstempel überlaufen bei 2.147.483.647 - 19. Januar 2038, 03:14:07 UTC - Verpackung bis Dezember 1901. Moderne 64-Bit-Systeme sind nicht betroffen, aber eingebettete 32-Bit-Geräte, älterer C-Code und MySQL TIMESTAMP Spalten werden freigelegt. Systeme Computing Far-Future-Daten (Hypotheken, Zertifikate) trifft den Fehler Jahre vor dem Eintreffen von 2038.

Warum zeigt mein Datum Januar 1970?

Ein Zeitstempel von null oder nahe Null erreichte Ihren Formatierungscode - normalerweise ein nicht initialisierter Wert, ein fehlgeschlagener Parse, der 0 zurückgibt, oder Sekunden, an denen Millisekunden erwartet wurden. Ein Datum von 1970 auf dem Bildschirm ist fast nie ein Datenpunkt, es ist ein Null-Träger.

Sollte ich Zeitstempel oder DateTime-Strings in meiner Datenbank speichern?

Speichern Sie UTC so oder so - der Typ ist weniger wichtig als die Zeitzonendisziplin. Unix-Ganzzahlen sind kompakt, sortieren und sortieren vollständig aus. timestamptz/DATETIME Spalten sind in Abfrageergebnissen lesbar und unterstützen Datumsarithmetik in SQL. Was Sie nicht tun dürfen, ist lokale Zeiten ohne Offsets zu speichern – das ist Datenverlust, den Sie erst beim nächsten DST-Übergang entdecken.

Wird die Epoche von Schaltsekunden beeinflusst?

Praktisch Nein. Unix-Zeit gibt vor, dass Schaltsekunden nicht existieren - jeder Tag beträgt genau 86.400 Sekunden, und Systeme schmieren oder treten normalerweise die Uhr, wenn eine Schaltsekunde auftritt. Für den Anwendungscode ist dies kein Problem, es ist nur in wissenschaftlichen Zeitkontexten von Bedeutung, in denen stattdessen TAI- oder GPS-Zeit verwendet wird.

Ist es sicher, Zeitstempel für das Produktionsprotokoll in einen Online-Konverter einzufügen?

Ein roher Zeitstempel allein zeigt wenig an, aber Zeitstempel reisen normalerweise mit Kontext - Benutzer-IDs, Token-Ansprüche, Log-Linien. der Zeitstempelkonverter Auf toolz.dev konvertiert ganz in Ihrem Browser keine Daten übertragen, so dass Werte direkt aus Produktionsprotokollen oder JWTs einfügen, was nicht fehlen.

Wie konvertiere ich einen Unix-Zeitstempel in ein lesbares Datum?

Fügen Sie die Zahl in einen Konverter ein und lesen Sie die UTC- und lokalen Ergebnisse oder tun Sie dies im Code: new Date(ts * 1000).toISOString() In Javascript, datetime.fromtimestamp(ts, tz=timezone.utc) In Python, date -u -d @ts Unter Linux. Das eine, was Sie zuerst richtig machen müssen, ist, ob Ihr Wert in Sekunden oder Millisekunden liegt - alles andere folgt daraus.

Wie bekomme ich den aktuellen Unix-Zeitstempel?

date +%s In einer Schale, Math.floor(Date.now() / 1000) In Javascript, int(time.time()) In Python, SELECT EXTRACT(EPOCH FROM NOW()) In PostgreSQL. Beachten Sie, dass JavaScript das Ungewöhnliche ist: Date.now() Gibt Millisekunden zurück, sodass die Aufteilung nicht optional ist.