Als im Jahr 2000 der „Millennium-Bug“ Schlagzeilen machte, ging es fast ausschließlich um Software – zweistellige Jahreszahlen, falsche Datenbanken, drohendes Chaos in Verwaltung und Industrie. Der große Crash blieb aus, doch die Lektion war klar: Zeitdarstellung ist fehleranfällig.
Heute steht mit dem Y2K38 Bug das nächste Zeitproblem bevor. Die Ursache: Viele Systeme speichern Zeit als 32-Bit-Integer (time_t), der die Sekunden seit dem 1. Januar 1970 zählt. Am 19. Januar 2038 läuft dieser Zähler über, was Programme abrupt ins Jahr 1901 zurückfallen lässt. Deshalb konzentrieren sich die meisten Maßnahmen bisher auf Software-Fixes – vom Linux-Kernel bis zu glibc – um time_t auf 64 Bit zu erweitern.
Doch das ist nur die halbe Wahrheit: Auch Hardware ist betroffen. In Hardware RTCs und anderen Chips – SoCs und FPGAs – sitzen seit Jahrzehnten 32-Bit-Sekundenzähler, die genauso ins Limit laufen. Während die Software-Welt auf 64 Bit umstellt, tickt die Zeitbombe im Silizium weiter – unscheinbar, aber gefährlich für langlebige Systeme.
Der Y2K38 Bug – das Jahr 2038 Problem
Der Y2K38 Bug ist ein Überlaufproblem in der Zeitdarstellung vieler Computer- und Embedded-Systeme. Seit den 1970er Jahren speichern zahlreiche Betriebssysteme Zeit als 32-Bit-Integer: Sekunden seit dem 1. Januar 1970 (Unix-Epoche).
Das Problem: Ein vorzeichenbehafteter 32-Bit-Wert kann maximal 2.147.483.647 Sekunden darstellen. Dieser Zeitpunkt entspricht dem 19. Januar 2038, 03:14:07 UTC. Danach läuft der Zähler über und springt ins Negative. Für das System wirkt es so, als sei das Datum im Dezember 1901 – mit fatalen Folgen für alle Programme, die auf korrekte Zeitangaben angewiesen sind.
Die meisten Maßnahmen konzentrieren sich aktuell auf Software – etwa den Wechsel von 32-Bit-time_t auf 64-Bit. Doch genau hier lauert die Gefahr: Auch viele Hardware RTCs und andere Chips basieren intern auf einem 32-Bit-Sekundenzähler. Diese laufen zwar technisch bis zum Jahr 2106, können aber in Kombination mit Software schon 2038 falsche Werte liefern.
Was ist eine Real Time Clock (RTC)?
Eine RTC (Real-Time Clock) ist ein Chip oder ein Modul, das die „echte Zeit“ in Form von Uhrzeit und Datum speichert. Sie liefert das einzig gültige „Jetzt“ für ein Computersystem – unabhängig davon, ob der Prozessor läuft oder das Gerät gerade ausgeschaltet ist.
Dadurch dient die RTC als stabiler Zeitbezug für:
- Betriebssysteme und Anwendungen
- Logs und Messwerte
- alle Arten von Zeitstempeln in Dateien, Protokollen und Steuerungen
Ohne eine RTC könnte würde ein System nach jedem Neustart die Zeit verlieren. Wenn die Software schläft, arbeitet die Hardware weiter.
Es gibt zwei grundlegende Arten:
- Kalender-RTCs – speichern Tag, Monat, Jahr, Stunde, Minute, Sekunde direkt in Registern
- Counter-RTCs – speichern die Zeit als fortlaufenden Sekundenwert, oft in einem 32-Bit-Register
Gerade diese 32-Bit-Counter-RTCs sind vom Y2K38 Bug betroffen, wenn ihre Werte auf die übliche Weise (als vorzeichenbehaftete 32-Bit-Zahl) interpretiert werden.
👉 Externe Counter-RTCs mit 32-Bit-Sekundenzählern sind weit verbreitet – von Industrieanlagen bis hin zu IoT-Geräten. Genau diese Popularität macht sie so kritisch: Was jahrzehntelang als robuste Standardlösung galt, wird spätestens 2038 zur Schwachstelle und erfordert rechtzeitige Aufmerksamkeit.
Welche Hardware RTCs sind vom Y2K38 Bug betroffen?
Nicht alle RTCs sind gefährdet. Kalender-RTCs wie der bekannte DS1307 oder DS3231 speichern Tag, Monat und Jahr getrennt – sie haben zwar eigene Grenzen (z. B. das Jahr 2100 wegen des Schaltjahres), sind aber nicht direkt vom Y2K38 Bug betroffen.
Anders ist die Situation bei den Counter-RTCs. Diese speichern die Zeit als fortlaufende Sekunden in einem 32-Bit-Register – genau hier entsteht das Risiko. Besonders bekannt sind die eigenständigen RTC-Bausteine von Dallas/Maxim (heute Analog Devices), die in vielen Embedded-Systemen und Industrieanlagen im Einsatz sind.
Einige betroffene Modelle sind nachfolgend beispielhaft aufgeführt:
Integrierte Hardware RTCs in Mikrocontrollern
Neben eigenständigen RTC-Bausteinen enthalten auch viele Mikrocontroller-Familien eingebaute Echtzeituhr-Module mit 32-Bit-Sekundenzähler. Diese sind ebenso anfällig für den Y2K38 Bug:
- STMicroelectronics STM32 (F1, F2, F3, F4) – ältere Generationen nutzen ausschließlich einen 32-Bit-Sekundenzähler. Damit sind sie klar vom Y2K38 Bug betroffen.
- NXP LPC-Serie (LPC2000, LPC1700, LPC1800) – weit verbreitete ARM7/ARM Cortex-M Controller mit 32-Bit-RTC.
- NXP/Freescale Kinetis K-Serie – ebenfalls mit 32-Bit-RTC, häufig in Automotive und Consumer-Elektronik eingesetzt.
- Silicon Labs EFM32 Gecko – Low-Power-MCUs mit 32-Bit-RTC, beliebt in IoT-Geräten.
- Microchip PIC32 (PIC32MX, PIC32MZ) – verfügen über integrierte 32-Bit-Sekundenzähler als RTC.
- Texas Instruments CC1310 / CC13xx / CC26xx – SimpleLink-MCUs mit 32-Bit-RTC; TI bestätigt hier ein Limit bereits um 2036 (bedingt durch NTP-Epochenhandling).
- Texas Instruments MSP430 (bestimmte Varianten) – auch hier sind RTC-Module mit 32-Bit-Timer verbreitet.
👉 Fazit: Nicht nur externe RTC-Chips sind betroffen, sondern ganze MCU-Familien. Besonders die älteren STM32, NXP LPC und TI SimpleLink-Controller sind noch lange im Feld und bringen den Y2K38 Bug direkt im Silizium mit.
Der Y2K38 Bug – hart verdrahtet in Chips
Zeitoperationen sind nicht nur ein Softwarethema. In vielen FPGAs und dedizierten ASICs sind sie direkt in die Hardware eingebaut – fest verdrahtet und damit nicht ohne Weiteres erweiterbar.
Die Ursache liegt auch darin, dass sich die Unixzeit besonders leicht in Hardware umsetzen lässt: ein einfacher Sekundenzähler im 2er-Komplement-Format reicht aus, um die aktuelle Zeit darzustellen. Solche Zähler lassen sich mit geringem Aufwand in VHDL oder Verilog beschreiben und in FPGAs oder ASICs implementieren. Genau diese Einfachheit hat dazu geführt, dass viele Hardwaredesigns seit Jahrzehnten auf 32-Bit-Register setzen.
Das Problem zeigt sich nun bei fest verdrahteten Protokoll-Engines: Das NTP-Format verwendet ein 32-Bit-Sekundenfeld, das schon 2036 überläuft. Auch CAN-Controller, SCADA-Prozessoren oder Logging-Engines in ASICs nutzen oft fest verankerte 32-Bit-Zeitstempel. In solchen Designs ist das Limit buchstäblich im Silizium eingebaut – und damit nicht ohne grundlegende Überarbeitung lösbar.
👉 Damit wird klar: Es ist kein reiner Software-Glitch – Der Y2K38 Bug ist eine strukturelle Grenze, zum Teil fest im Silizium verankert.
Der Retter im Silizium-Dilemma: Software-Treiber
Hardware mag das Problem in sich tragen – doch die erste Rettung kommt aus der Software. Mit clever geschriebenen und sauber gepflegten RTC-Treibern lassen sich viele Grenzen der 32-Bit-Zeitstempel abfangen, bevor sie ins Chaos führen.
Das Wichtigste dabei: Keine „Cast Aways“! Wer stumpf einen 32-Bit-Zähler in eine 64-Bit-Variable kopiert, kaschiert das Problem nur – und verlagert den Absturz. Stattdessen müssen Treiber die Rohdaten der Hardware bewusst in 64-Bit-Zeitmodelle übersetzen, inklusive korrektem Umgang mit Epochen, Überläufen und Offsets.
Auch Chips mit fest verdrahteten 32-Bit-Grenzen lassen sich durch geeignete Treiberanpassungen weiter zuverlässig nutzen. Während ein Austausch der Hardware aufwendig oder gar unmöglich ist, bieten Software-Updates und zusätzliche Abstraktionsschichten bereits heute praktikable Lösungswege.
Welche Möglichkeiten es konkret gibt und wie weit die Industrie bereits ist, werden wir von der BEOZ Association zu gegebener Zeit in einem eigenen Beitrag beleuchten.
