Unix Timestamp: Was es ist, Konvertierung und Speicherung in der mobilen Entwicklung

Was ist Unix Timestamp?

Unix Timestamp (auch bekannt als POSIX-Zeit, Epochenzeit oder Unix-Zeit) ist ein Zeitmesssystem, das die Anzahl der Sekunden definiert, die seit dem 1. Januar 1970 00:00:00 UTC (der Unix-Epoche) vergangen sind. Dieses Datum wurde als Startpunkt für das Betriebssystem Unix gewählt, und das Format wurde anschließend zum De-facto-Standard für die Darstellung von Zeit in Computersystemen. Der Timestamp berücksichtigt keine Schaltsekunden — jede Minute wird als 60 Sekunden gezählt, obwohl der Internationale Erdrotationsdienst gelegentlich eine zusätzliche Sekunde zur Korrektur der Atomzeit hinzufügt.

Die Unix-Epoche: Warum 1970?

Die Wahl des 1. Januar 1970 hängt mit der Geschichte des Betriebssystems Unix zusammen. Die Entwickler Ken Thompson und Dennis Ritchie wählten dieses Datum als einfachen runden Startpunkt — es war früh genug, um alle möglichen Daten aufzunehmen, und spät genug, dass die Zeit in einer 32-Bit-Ganzzahl mit Vorzeichen gespeichert werden konnte. Ursprünglich wurde die Zeit in Sechzigstelsekunden gemessen, dann in Ticks (1/60 Sekunde), und erst in der siebten Ausgabe von Unix (V7, 1979) stabilisierte sich das Format als ganze Anzahl von Sekunden. Laut The Open Group Base Specifications (Ausgabe 8, 2024) sind POSIX-konforme Systeme verpflichtet, dieses Format zu unterstützen.

Wie funktioniert Unix Timestamp

Das Funktionsprinzip des Unix Timestamp basiert auf einem einfachen Zähler: Jeder vergehende Tag addiert 86.400 Sekunden zum Wert. Beispielsweise entspricht der Timestamp 1.720.000.000 einem Datum Mitte 2024 — die genaue Umrechnung kann durch Division durch die Anzahl der Sekunden in einem Tag, einer Stunde und einer Minute erfolgen. Dieser Ansatz macht den Timestamp ideal für die maschinelle Speicherung: Es ist eine ganze Zahl, die 4 Byte (32-Bit-Int) oder 8 Byte (64-Bit-Long) belegt und direkte Vergleiche unterstützt — ein größerer Timestamp = ein späteres Datum.

Umrechnungsmathematik

Ein Tag = 86.400 Sekunden (24 x 60 x 60). Eine Stunde = 3.600 Sekunden. Um einen Timestamp in ein Datum umzuwandeln, müssen nacheinander die Anzahl der Tage, Stunden, Minuten und Sekunden seit der Epoche berechnet werden. Die umgekehrte Umrechnung — ein Datum in Tage seit 1970-01-01 umwandeln, dann mit 86.400 multiplizieren und den UTC-Offset addieren. In Java und Kotlin sind diese Berechnungen bereits in den Standardklassen java.time.Instant und java.util.Date implementiert, was den Entwickler von manuellen Berechnungen befreit.

        // Unix Timestamp in Sekunden abrufen
val seconds = System.currentTimeMillis() / 1000

// Timestamp per java.time in Datum umwandeln
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Umgekehrt: Datum in Timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Konvertierung von Unix Timestamp in Datum und zurück

Die Konvertierung eines Unix Timestamp in ein menschenlesbares Datum ist eine der häufigsten Operationen in der mobilen Entwicklung. Unter Android stehen je nach Mindest-API-Version mehrere Konvertierungsmethoden zur Verfügung: Für API 26+ wird java.time.Instant empfohlen, für ältere Versionen werden java.util.Date und java.text.SimpleDateFormat verwendet. Es ist wichtig zu beachten, dass Android und die JVM standardmäßig Millisekunden verwenden, nicht Sekunden — wenn ein Timestamp vom Server in Sekunden empfangen wird, muss er vor der Übergabe an Standardkonstruktoren mit 1000 multipliziert werden.

Zeitzonenbewusste Konvertierung

Einer der Hauptvorteile des Unix Timestamp ist die Standortunabhängigkeit. Der Server gibt den Timestamp immer in UTC zurück, und die Umrechnung in lokale Datum und Uhrzeit erfolgt auf der Clientseite. In Kotlin wird ZonedDateTime mit der entsprechenden ZoneId verwendet — entweder die System- oder eine benutzerdefinierte. Wenn eine Anwendung die Uhrzeit in verschiedenen Zeitzonen anzeigt (z. B. für Reisende), entfällt durch den Timestamp die Notwendigkeit, die Zeitzone vom Server zu übermitteln — ein einzelner Zeitmarker ist ausreichend.

// Mit Benutzerzeitzone konvertieren
fun formatTimestamp(seconds: Long, zoneId: ZoneId): String {
    val instant = Instant.ofEpochSecond(seconds)
    val formatter = DateTimeFormatter
        .ofPattern("dd.MM.yyyy HH:mm:ss")
    return formatter.format(instant.atZone(zoneId))
}

// Beispiel: timestamp = 1720000000, zone = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

Das Jahr-2038-Problem

Das Jahr-2038-Problem (Y2K38) ist eine grundlegende Einschränkung der Speicherung von Unix Timestamp als 32-Bit-Ganzzahl mit Vorzeichen. Der maximale Wert einer 32-Bit-Ganzzahl mit Vorzeichen ist 2.147.483.647, was dem 19. Januar 2038 um 03:14:07 UTC entspricht. Nach diesem Datum läuft der Wert über und wird zu einer negativen Zahl, was zu Fehlern in Systemen führt, die 32-Bit-time_t verwenden. Das Problem ist dem bekannten Y2K-Problem ähnlich, betrifft aber hauptsächlich eingebettete Systeme, ältere Android-Versionen und IoT-Geräte mit 32-Bit-Architektur.

Ausmaß des Problems

Laut Linux Foundation (2025) verwenden etwa 15% der Linux-Geräte in den Industrie- und IoT-Segmenten immer noch 32-Bit-Builds. Für Android-Geräte ist das Risiko geringer — die meisten modernen Smartphones laufen auf 64-Bit-Prozessoren (ARM64), aber ältere Modelle mit Android 4.x und darunter verwenden möglicherweise 32-Bit-time_t. Die Lösung ist die Migration zu 64-Bit-time_t, das für bis zu 292 Milliarden Jahre sicher ist. Ab Android 5.0 (API 21) verwenden alle Geräte 64-Bit-Zeit auf Kernelebene. Mobile Anwendungsentwickler müssen den Timestamp lediglich als Long (64-Bit) speichern, um das Problem auf Anwendungsebene zu vermeiden.

Arbeiten mit Unix Timestamp in Android

In der Android-Entwicklung ist die korrekte Handhabung von Unix Timestamp entscheidend für die Datensynchronisation, die Anzeige von Nachrichtenempfangszeiten, die Berechnung von Timeouts und die Planung von Benachrichtigungen. Der Systemaufruf System.currentTimeMillis() gibt die aktuelle Zeit in Millisekunden seit der Unix-Epoche zurück — dies ist die genaueste auf dem Gerät verfügbare Zeitquelle. Für Netzwerkanfragen wird normalerweise der Unix Timestamp in Sekunden verwendet, da die meisten REST-APIs und Datenbanken in Sekunden arbeiten.

Empfohlene Praktiken

Verwenden Sie niemals System.currentTimeMillis() zum Messen von Intervallen — für diesen Zweck gibt es System.nanoTime(), das monoton und von Benutzeruhränderungen nicht betroffen ist. Für die Zeitanzeige speichern Sie den Timestamp immer in UTC und konvertieren Sie ihn auf der UI-Seite in die lokale Zeitzone. Bei der Arbeit mit Datenbanken (SQLite, Room) verwenden Sie den Typ INTEGER und speichern den Timestamp in Sekunden — dies belegt 8 Byte (Long) und unterstützt native SQL-Sortierung. Für die JSON-Serialisierung empfiehlt es sich, den Timestamp als Zahl (Long) statt als String zu senden — das ist kompakter und wird schneller geparst.

// Korrekte Ausführungszeitmessung
val start = System.nanoTime()
// ... Vorgang ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// In Room (Entity) speichern
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp in Sekunden
)

Umgang mit Serverzeit

Beim Empfang eines Unix Timestamp vom Server überprüfen Sie immer die Maßeinheit: Einige APIs geben Millisekunden zurück (JavaScript-kompatibel), andere geben Sekunden zurück (POSIX-Standard). Die Vereinbarung über die Einheiten sollte in der API-Dokumentation festgehalten werden. In der Serverantwort kann der Timestamp als Long (JSON-Zahl) oder String (ISO 8601) übergeben werden. Fügen Sie für das Debugging eine Dienstprogrammfunktion hinzu, die den Timestamp in einem menschenlesbaren Format ausgibt — das vereinfacht die Überprüfung der Zeitmarker während der Entwicklung.

Speicherung von Zeitstempeln in Datenbanken

Die Wahl des Zeitspeicherformats in einer Datenbank wirkt sich direkt auf die Abfrageleistung, die Codekomplexität und die Korrektheit der Zeitzonenbehandlung aus. Unix Timestamp ist das effizienteste Format für relationale Datenbanken: Es wird als ganze Zahl (4 oder 8 Byte) gespeichert, unterstützt Indizierung und ermöglicht schnelle Sortierung. Im Gegensatz zu ISO-8601-Strings benötigt der Timestamp keine Analyse zum Sortieren und belegt weniger Platz in einem Index. Für Room und SQLite wird empfohlen, den Timestamp als INTEGER zu speichern und einen Index auf der Zeitspalte zu verwenden.

Empfehlungen für mobile Projekte

Für Android-Anwendungen mit der Room-Bibliothek empfiehlt es sich, Zeitstempel als Long (64-Bit) zu speichern und einen TypeConverter für die automatische Konvertierung zwischen Long und Date oder Instant zu verwenden. Verwenden Sie bei Datenbankabfragen Vergleichsoperatoren (>, <, BETWEEN) — sie arbeiten nativ mit Integer-Typen. Für das Caching von Daten, die eine zeitbasierte Sortierung erfordern (z. B. eine Nachrichtenliste), erstellen Sie immer einen Index auf der Timestamp-Spalte — dies beschleunigt Abfragen mit ORDER BY bei großen Datenmengen um mehrere Größenordnungen.