![\"F\u00fcnf](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/zeitstempel-umrechnen-de.png?v=20260925\")
F\u00fcnf Formate, die in einem Stapel zusammentreffen<\/h2>\n
Alle z\u00e4hlen vom selben Nullpunkt: Mitternacht am 1. Januar 1970, in UTC. Verschieden sind Einheit und Verpackung.<\/p>\n
| Format<\/th>\n | Beispiel<\/th>\n | Wo es auftritt<\/th>\n<\/tr>\n<\/thead>\n |
|---|---|---|
| Sekunden<\/td>\n | 1790465400<\/td>\n | Meta-CAPI event_time, die meisten REST-Schnittstellen<\/td>\n<\/tr>\n |
| Millisekunden<\/td>\n | 1790465400000<\/td>\n | Date.now(), gtm.start, das meiste JavaScript<\/td>\n<\/tr>\n |
| Mikrosekunden<\/td>\n | 1790465400000000<\/td>\n | GA4-BigQuery event_timestamp<\/td>\n<\/tr>\n |
| ISO 8601<\/td>\n | 2026-09-27T01:30:00+02:00<\/td>\n | Protokolle, Search-Console-API, die meisten Exporte<\/td>\n<\/tr>\n |
| Nur Datum<\/td>\n | 20260927<\/td>\n | GA4 event_date, BigQuery-Tabellensuffix<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Die ersten drei sind eindeutig – eine Anzahl Einheiten seit einem festen Punkt und tragen keine Zeitzone, weil sie keine brauchen. Das vierte ist eindeutig, solange es einen Versatz tr\u00e4gt – das Das f\u00fcnfte ist von anderer Art. Ein Datum ohne Uhrzeit ist kein Augenblick, sondern ein Bereich von vierundzwanzig Stunden – und welche vierundzwanzig Stunden das sind, h\u00e4ngt an einer Zeitzone, die im Wert nirgends steht.<\/p>\n F\u00fcr eine Zahl aus einem Protokoll, einem Export oder einer Nutzlast entscheidet die L\u00e4nge.<\/p>\n Aus dem \u00dcbergehen entstehen zwei Fehler, und beide erzeugen ein Ergebnis, das plausibel aussieht. Millisekunden als Sekunden zu lesen verschiebt das Datum ins Jahr 58 707 – offensichtlich falsch und damit harmlos. Sekunden als Millisekunden zu lesen verschiebt es auf den 21. Januar 1970, was \u00fcberhaupt nicht offensichtlich falsch ist und in einem Bericht als winziger Balken ganz links in jedem Diagramm erscheint.<\/p>\n Eine Absicherung kostet drei Zeilen und lohnt sich \u00fcberall dort, wo ein Wert von au\u00dfen ankommt.<\/p>\n Der GA4-BigQuery-Export tr\u00e4gt sowohl einen Augenblick als auch ein Datum, und beide folgen verschiedenen Konventionen.<\/p>\n Das ist kein Fehler und l\u00e4sst sich nicht abschalten. Es ist der Grund, weshalb zwei Abfragen \u00fcber dieselbe Tabelle verschiedene Tagessummen liefern k\u00f6nnen – und der Unterschied hat immer dieselbe Gr\u00f6\u00dfe: die Ereignisse der ersten ein bis zwei Stunden jedes Tages.<\/p>\n Die Regel daraus ist kurz. Eine Gruppierung nach Tagen verwendet entweder durchgehend Drei Funktionen decken jeden Fall ab, und jede tr\u00e4gt die Einheit im Namen.<\/p>\n Der Unterschied zwischen In die andere Richtung wird aus einer Zeichenkette nur mit angegebenem Format ein Zeitstempel – und die Formatangabe ist die Stelle, an der ein Versatz entweder gelesen oder erfunden wird.<\/p>\n Zwei empfangende Systeme pr\u00fcfen den Wert, statt ihn nur zu speichern, und beide scheitern auf eine leicht zu \u00fcbersehende Weise.<\/p>\n Die Meta Conversions API nimmt ein Ein Zeitstempel in der Zukunft ist die andere H\u00e4lfte derselben Regel und kommt h\u00e4ufiger vor als die Vergangenheit: Ein Server, dessen Uhr einige Minuten vorgeht, erzeugt Ereignisse, die die Plattform ablehnt. Ein scheiternder Abschluss-Upload lohnt sich deshalb als Uhrenproblem zu untersuchen, bevor er als Datenproblem untersucht wird.<\/p>\n Uploads von Offline-Abschl\u00fcssen an Werbeplattformen wollen meist eine Ortszeit mit ausdr\u00fccklichem Versatz statt eines Epochenwerts.<\/p>\n Der Versatz ist keine Zierde. Ohne ihn wendet die Plattform die Zeitzone des Kontos an, und ein Konto in einer anderen Zone als der Shop verschiebt jeden Abschluss um die Differenz – was als Abschl\u00fcsse am falschen Tag erscheint und an einer Monatsgrenze im falschen Monat.<\/p>\n Alles Bisherige ist eine Umrechnung. Diese beiden sind Verluste, und das einzige Mittel ist, sie nicht entstehen zu lassen.<\/p>\n Die erste ist eine Ortszeit ohne Versatz. Die zweite ist die Umstellungsnacht. Bei der R\u00fcckstellung geschieht die Stunde zwischen zwei und drei Uhr zweimal, und eine Ortszeit darin ist selbst bei bekannter Zone wirklich mehrdeutig. Ein Versatz l\u00f6st das auf, denn die beiden Durchg\u00e4nge haben verschiedene Vers\u00e4tze. Ein Zonenname allein tut es nicht.<\/p>\n Beides verschwindet, wenn Werte als UTC gespeichert und nur zur Anzeige umgerechnet werden. Das ist eine einzeilige Regel, die selbstverst\u00e4ndlich klingt und st\u00e4ndig gebrochen wird, denn eine Ortszeit ist das, was ein Mensch lesen m\u00f6chte – und die Abhilfe besteht darin, beim Lesen umzurechnen statt beim Schreiben.<\/p>\n Mit gro\u00dfer Wahrscheinlichkeit Nanosekunden seit der Epoche. Dieses Format verwenden zum Beispiel OpenTelemetry und die Funktion UnixNano in Go; in einem Tracking-Stapel taucht es vor allem in Server- und Protokolldaten auf. Die Absicherung weist es zu Recht ab, statt zu raten, und l\u00e4sst sich um eine Zeile f\u00fcr 19 Stellen mit dem Teiler Heute ja, aber knapp. JavaScript speichert Zahlen als Gleitkommazahlen doppelter Genauigkeit, und ganze Zahlen sind damit nur bis 9\u00a0007\u00a0199\u00a0254\u00a0740\u00a0991 exakt ( Nanosekunden liegen dagegen weit dar\u00fcber. Ein 19-stelliger Wert verliert beim Einlesen mit Das beseitigt den Unterschied zwischen event_date und dem Zeitstempel, verschiebt das Problem aber an eine andere Stelle. Alle Tagesberichte in GA4 beginnen dann um Mitternacht UTC, f\u00fcr einen Shop in Berlin also um ein Uhr im Winter und um zwei Uhr im Sommer. Ein Einkauf um halb eins in der Nacht z\u00e4hlt zum Vortag, und die Tageswerte passen nicht mehr zu Kasse, Warenwirtschaft und Werbekonten, die in Ortszeit rechnen.<\/p>\n Dazu kommt der Wechsel selbst. Eine ge\u00e4nderte Berichtszeitzone gilt nur f\u00fcr Daten ab der Umstellung, fr\u00fchere Tage bleiben, wie sie waren. Der Tag der Umstellung ist deshalb k\u00fcrzer oder l\u00e4nger als vierundzwanzig Stunden, und eine Zeitreihe \u00fcber den Wechsel hinweg stellt Berliner Tage neben UTC-Tage.<\/p>\n Tragf\u00e4higer ist die Regel aus dem Artikel: Die Property beh\u00e4lt die Zone, in der das Gesch\u00e4ft rechnet, und jede Abfrage entscheidet sich f\u00fcr eine Konvention. Eine Gruppierung nach Berliner Tagen in BigQuery hat dann dieselben Tagesgrenzen wie die Oberfl\u00e4che, und eine Gruppierung nach UTC ist die bewusste Wahl eines anderen Tages.<\/p>\n Mit zwei Proben. Auf dem Server selbst zeigt Liegt sie im Bereich von Minuten, verschwindet sie, sobald der Abgleich mit einem Zeitserver l\u00e4uft. Ereignisse, die mit falscher Zeit gesendet und abgewiesen wurden, sind danach mit korrigiertem Zeitstempel erneut zu senden, solange sie noch im Fenster von sieben Tagen liegen.<\/p>\n<\/div>\n |