Wie Sie zwischen Zeitformaten konvertieren

Zeitformate unterscheiden sich zwischen Systemen, APIs und Ländern. Unix-Timestamps in API-Antworten, ISO 8601 in Datenbanken, 12-Stunden-Uhren in den USA, 24-Stunden-Uhren in Europa: Zwischen ihnen umzurechnen ist für Entwickler und alle, die mit internationalen Daten arbeiten, ein ständiger Bedarf. Zu verstehen, warum jedes Format existiert, wo es glänzt und wo es beißt, macht die Umrechnung zu einem schnellen Reflex statt zu einer wiederkehrenden Quelle subtiler Bugs.

Eine kurze Geschichte der Zeitformate

Zeit zu standardisieren ist älter als das Internet. 1884 legte die Internationale Meridiankonferenz die Greenwich Mean Time und den Nullmeridian fest, was der Welt zum ersten Mal eine gemeinsame Referenz gab. Die 24-Stunden-Uhr verbreitete sich aus demselben Grund in Luftfahrt und Militär: Sie beseitigt die AM/PM-Mehrdeutigkeit, die eine Mitternachts-Buchung in einen Mittagsflug verwandelt.

Unix-Zeit kam mit dem ursprünglichen Unix-Kernel 1971 und zählt Sekunden seit dem 1. Januar 1970 UTC (der «Epoche»). Die Wahl war pragmatisch: Ein 32-Bit-Integer konnte Jahrzehnte abdecken, das Sortieren von Timestamps war das Sortieren von Zahlen, und das Berechnen von Intervallen war eine Subtraktion. ISO 8601 kam 1988, um die menschenlesbare Seite zu standardisieren: Jahr-Monat-Tag in Big-Endian-Reihenfolge, T als Datum/Zeit-Trenner und Z für UTC. RFC 3339 (2002) ist ein engeres Profil von ISO 8601, das für Internet-Protokolle ausgelegt ist. RFC 2822 (2001) definiert das E-Mail-Format mit Tagesnamen und Offsets. Jedes Format löst ein echtes Problem; keines ersetzt die anderen vollständig.

Gängige Zeitformate

Sechs Formate decken fast alles ab, was Ihnen in der Praxis begegnet. Die erste Spalte ist der Name, den Sie in der Dokumentation sehen; die Beispielspalte zeigt, wie 14:30 Uhr am 7. April 2024 UTC aussieht.

Die meisten Teams einigen sich auf Unix-Millisekunden für Speicherung und ISO 8601 für Übertragung, mit Anzeigeformaten pro Locale. Die Wahl zählt weniger als Konsistenz: Wählen Sie ein Hauptformat, dokumentieren Sie es und konvertieren Sie an den Rändern.

Schnelle Umrechnungsreferenz

12 Stunden zu 24 Stunden

Die 12-Stunden-Uhr hat zwei Eigenheiten: 12 AM ist Mitternacht (der Tagesanfang) und 12 PM ist Mittag. Die Tabelle unten deckt die Fälle ab, die Leuten Probleme machen.

Timestamps zu Daten

Der Epoch-Konverter übersetzt Unix-Timestamps sofort in lesbare Daten und zurück. Der Konverter erkennt automatisch sowohl Sekunden- (10 Stellen) als auch Millisekunden-Formate (13 Stellen), sodass Sie einen Wert aus jeder Quelle einfügen können, ohne sich um die Einheit zu sorgen.

Ein nützlicher Plausibilitäts-Check: Teilen Sie durch 86400 (Sekunden pro Tag) und addieren Sie 1970 Tage, um jeden Timestamp im Kopf zu verorten. 1712502600 / 86400 ~ 19820 Tage, also etwa 54 Jahre nach 1970, was ihn in 2024 setzt. Nicht präzise, aber genug, um 1000er-Faktor-Fehler auf einen Blick zu erkennen.

Umrechnungsbeispiele in Code

Die meisten Entwickler müssen Timestamps irgendwann im Code umrechnen. Die Kern-APIs sind kurz:

• JavaScript, new Date(1712502600 * 1000).toISOString() gibt 2024-04-07T14:30:00.000Z zurück. Denken Sie daran, mit 1000 zu multiplizieren, weil JavaScripts Date Millisekunden erwartet. Andersherum: Math.floor(Date.now() / 1000) liefert einen Sekunden-Timestamp.
• Python, datetime.fromtimestamp(1712502600, tz=timezone.utc).isoformat() gibt 2024-04-07T14:30:00+00:00 zurück. Vermeiden Sie utcfromtimestamp(); es gibt ein naives Datetime zurück, das der Rest Ihres Codes fälschlich als lokale Zeit behandelt.
• Go, time.Unix(1712502600, 0).UTC().Format(time.RFC3339) gibt 2024-04-07T14:30:00Z zurück. Gos time-Paket ist ungewöhnlich, aber konsistent, sobald Sie das Referenz-Layout Mon Jan 2 15:04:05 MST 2006 verinnerlicht haben.
• Shell, date -u -d @1712502600 +"%Y-%m-%dT%H:%M:%SZ" auf GNU/Linux, oder date -u -r 1712502600 +"%Y-%m-%dT%H:%M:%SZ" auf BSD/macOS. Der Flag-Unterschied ist einer der am häufigsten gegoogelten plattformübergreifenden Stolpersteine.
• Rust, chrono::DateTime::<chrono::Utc>::from_timestamp(1712502600, 0).unwrap().to_rfc3339() gibt denselben ISO-String zurück. Die Standardbibliothek hat jetzt SystemTime, aber chrono ist immer noch die praktische Wahl für Formatierung.
• SQL (Postgres), SELECT to_timestamp(1712502600) AT TIME ZONE 'UTC'; gibt ein timestamptz zurück. MySQL nutzt FROM_UNIXTIME(); SQLite nutzt datetime(1712502600, 'unixepoch').

Ein Konverter-Tool ist schneller als jeder dieser Einzeiler, wenn Sie nur einen einzelnen Wert übersetzen müssen, was beim Debuggen meist der Fall ist.

Warum ISO 8601 für Speicherung gewinnt

ISO 8601 (und das RFC-3339-Profil davon) sortiert korrekt als reine Zeichenkette. 2024-04-07T14:30:00Z kommt alphabetisch vor 2024-04-07T15:00:00Z, das vor 2024-04-08T00:00:00Z kommt. Diese Eigenschaft erlaubt es Ihnen, Timestamps ohne Parsen zu sortieren, Logzeilen mit sort | uniq -c zu gruppieren und über Bereiche mit einfachen String-Vergleichen zu räsonieren.

Es ist auch eindeutig auf eine Weise, die die regionalen Formate nicht sind. 04/07/2024 könnte der 7. April (USA) oder der 4. Juli (großer Teil Europas) sein; 2024-04-07 ist in jeder Locale dasselbe. Für Maschine-zu-Maschine-Austausch ist diese Eindeutigkeit mehr wert als jede andere Formatierungs-Überlegung.

Häufige Fallstricke, die zu vermeiden sind

• Zeitzone vergessen, 2026-04-07 14:30 ist ohne Zone mehrdeutig. Fügen Sie beim Speichern von ISO-Strings immer Z oder einen +00:00-Offset ein, und verlassen Sie sich nie auf die Standardzone des Lesers.
• Sekunden und Millisekunden vermischen, ein 10-stelliger Unix-Timestamp ist in Sekunden, ein 13-stelliger in Millisekunden. Sie zu mischen produziert Daten entweder in 1970 oder weit in der Zukunft. Mikrosekunden (16 Stellen) und Nanosekunden (19 Stellen) schleichen sich auch ein, also rechnen Sie damit.
• Sich auf lokale Zeit in Servern verlassen, wenn Ihr Server in UTC läuft und Ihr Benutzer in Tokio ist, speichern Sie UTC und konvertieren Sie bei der Anzeige. Den Server die Locale ableiten zu lassen führt fast immer zu Bugs, wenn Benutzer reisen oder die Sommerzeit umstellt.
• Mit String-Mathematik parsen, schneiden und verketten Sie keine Datums-Strings. Verwenden Sie Date.parse(), dateutil.parser, chrono oder die Standardbibliothek Ihrer Sprache. Manuelles Parsen bricht bei Extremdaten, Schaltjahren und Zeitzonen-Offsets.
• Auf new Date("2024-04-07") vertrauen, JavaScript parst reine Datums-Strings als UTC-Mitternacht, aber Datums-Zeit-Strings ohne Zone als lokale Mitternacht. Das Verhalten unterscheidet sich zwischen Browsern und Node-Versionen. Fügen Sie immer ein explizites Z oder einen Offset ein.
• Zweistellige Jahre, 04/07/24 könnte je nach Implementierung 1924, 2024 oder 2124 sein. Verwenden Sie überall vierstellige Jahre.
• Sommerzeit-Umstellungen, die lokale Uhr überspringt im Frühjahr eine Stunde und wiederholt eine im Herbst. Ein naiver Scheduler kann einen Job an diesen Tagen zweimal oder gar nicht ausführen. Verwenden Sie UTC für Scheduling-Logik und konvertieren Sie nur zur Anzeige.
• Schaltsekunden, Unix-Zeit tut so, als existierten sie nicht, indem sie die betroffene Sekunde verschmiert oder wiederholt. Code, der «verstrichene Sekunden» vergleicht, kann kurz von einer Wanduhr abweichen, die Schaltsekunden respektiert.
• Das Jahr-2038-Problem, 32-Bit-signed-time_t läuft am 19. Januar 2038 über. Die meisten modernen Systeme nutzen 64-Bit-Zeit, aber alte Embedded-Geräte und alte Datenbankspalten können noch darauf treffen. Auditieren Sie überall, wo Sie INT4 oder int32 für Timestamp-Speicherung sehen.
• Locale-abhängige Formatierung, toLocaleString() in JavaScript und vergleichbare Funktionen in anderen Sprachen produzieren auf verschiedenen Maschinen unterschiedliche Ausgaben. Für maschinenlesbare Timestamps nutzen Sie toISOString() oder das Äquivalent; für Anzeige formatieren Sie explizit.

Alternative Werkzeuge und Bibliotheken

Ein Konverter erledigt den Einzelfall; für Produktionscode greifen Sie zu einer Bibliothek.

Die richtige Bibliothek hängt von Ihrem Stack ab; die richtige Disziplin ist überall gleich: UTC speichern, ISO 8601 übertragen, nur zur Anzeige formatieren und nie einem Timestamp ohne explizite Zone trauen.

Datenschutz und der Konverter

Der Zeitformat-Konverter läuft vollständig in Ihrem Browser. Die Timestamps, die Sie einfügen, und die Daten, die Sie erzeugen, verlassen die Seite nie. Es gibt kein Server-Log, welche Werte umgerechnet wurden, keine Analytik dazu, welche Formate populär sind, und keine Möglichkeit für irgendjemanden, eine Anfrage mit Ihrer IP zu verknüpfen. Zeitumrechnungen sind an sich keine persönlichen Daten, aber die Timestamps in Ihren Logs (Login-Zeiten, Transaktionszeiten, Scheduling-Fenster) sind es oft, und sie durch einen Drittanbieter-Konverter zu schicken könnte operative Details verraten. Die Arbeit clientseitig zu erledigen, hält diese Information auf Ihrer Maschine, wo sie hingehört. Für eine Aufgabe, die so routiniert ist wie das Umschalten zwischen Sekunden und ISO 8601, sollte die Datenschutz-Voreinstellung sein: keine Übertragung, kein Logging, kein Dritter in der Schleife.