DE
RU
EN
ES
ZH
FR
PT
AR
HI
Einleitung: Der Bug, der jeden erwischt hat
\n\nHaben Sie jemals in Ihren Logs das Datum 0001-01-01 00:00:00 +0000 UTC gesehen und sich gefragt: „Wo kommt das her? Ich habe doch gar nichts initialisiert!“? Herzlichen Glückwunsch, Sie sind auf das Zero Value von time.Time in Go gestoßen. Das ist eine klassische Falle, die auf Stack Overflow tausende Aufrufe und weltweit hunderte Stunden Debugging verursacht.
In diesem Artikel erklären wir, was das Zero Value für time.Time ist, warum es sich unerwartet verhält, wie Sie ein „leeres“ Datum von einem echten unterscheiden und – vor allem – wie Sie diese Stolpersteine im Produktivbetrieb vermeiden. Wenn Sie in Go programmieren und mit Daten arbeiten, wird Ihnen dieser Beitrag viel Nerven sparen.
\n\nWas ist ein Zero Value in Go und warum ist time.Time ein Sonderfall?
\n\nIn Go hat jeder Typ einen Nullwert (Zero Value). Für Zahlen ist das 0, für Strings "", für Zeiger nil. Die Logik ist einfach: Wenn Sie eine Variable ohne Initialisierung deklarieren, erhält sie einen „Platzhalter“. Aber bei time.Time ist es komplizierter.
Der Nullwert von time.Time ist nicht der Unix-Timestamp 0 (1970-01-01), wie man erwarten könnte. Es ist 0001-01-01 00:00:00 +0000 UTC. Warum? Weil time.Time intern die Nanosekunden seit dem 1. Januar des Jahres 1 (nach gregorianischem Kalender) speichert. Die Null in dieser Darstellung ergibt das Jahr 1.
package main\n\nimport (\n "fmt"\n "time"\n)\n\nfunc main() {\n var t time.Time\n fmt.Println(t) // 0001-01-01 00:00:00 +0000 UTC\n fmt.Println(t.Unix()) // -62135596800 (negative Zahl!)\n}\nSehen Sie das Problem bereits? Wenn Sie versuchen, mit if t == 0 zu prüfen oder mit dem Unix-Nullpunkt zu vergleichen, wird Ihr Code fehlschlagen. Lassen Sie uns die Top-Fehler mit dem Zero Value von time.Time und deren Vermeidung durchgehen.
Die Top 5 Fehler mit dem Zero Value von time.Time
\n\n1. Vergleich mit Unix-Timestamp 0
\n\nDer häufigste Fehler ist der Versuch, zu prüfen, ob eine Zeit „leer“ ist, indem man sie mit time.Unix(0, 0) vergleicht. Das funktioniert nicht, weil der Nullwert nicht das Jahr 1970 ist.
// ❌ Fehler: Wird niemals true ergeben\nvar t time.Time\nif t == time.Unix(0, 0) {\n fmt.Println("Zeit ist leer")\n}\n\n// ✅ Richtig: Die Methode IsZero() verwenden\nif t.IsZero() {\n fmt.Println("Zeit ist leer")\n}\nDie Methode IsZero() ist Ihr wichtigstes Werkzeug. Sie gibt true nur für den Nullwert zurück, nicht für ein beliebiges „frühes“ Datum.
2. JSON-Serialisierung: Unerwartetes null
\n\nWenn Sie eine Struktur mit time.Time in JSON serialisieren, wird der Nullwert in den String "0001-01-01T00:00:00Z" umgewandelt. Das zerstört APIs, Frontends und Datenbanken. Clients sehen ein seltsames Datum anstelle von null.
type Event struct {\n Name string `json:"name"`\n StartTime time.Time `json:"start_time"`\n}\n\nfunc main() {\n e := Event{Name: "test"}\n data, _ := json.Marshal(e)\n fmt.Println(string(data))\n // {"name":"test","start_time":"0001-01-01T00:00:00Z"}\n // ❌ Sollte null sein oder das Feld fehlen\n}\nLösung: Verwenden Sie einen Zeiger auf time.Time (*time.Time) oder einen benutzerdefinierten Typ mit Serialisierungslogik.
// ✅ Variante mit Zeiger\ntype Event struct {\n Name string `json:"name"`\n StartTime *time.Time `json:"start_time,omitempty"`\n}\n\n// ✅ Oder benutzerdefinierter Typ mit omitempty\ntype CustomTime struct {\n time.Time\n}\n\nfunc (ct CustomTime) MarshalJSON() ([]byte, error) {\n if ct.IsZero() {\n return []byte("null"), nil\n }\n return json.Marshal(ct.Time)\n}\n3. Probleme mit Datenbanken (SQL)
\n\nBeim Einfügen eines Nullwerts von time.Time in PostgreSQL oder MySQL erhalten Sie das Datum 0001-01-01, was einen Bereichsfehler auslöst (Jahr 1 liegt außerhalb des gültigen Bereichs).
