Unix Timestamp: wat is het, conversie en opslag in mobiele ontwikkeling

Wat is Unix Timestamp?

Unix Timestamp (ook bekend als POSIX time, Epoch time of Unix time) — is een tijdmeetsysteem dat het aantal seconden bepaalt dat is verstreken sinds 1 januari 1970 00:00:00 UTC (het Unix-tijdperk). Deze datum is gekozen als het beginpunt voor de telling voor het Unix-besturingssysteem, en later werd het formaat de de facto standaard voor tijdweergave in computersystemen. Timestamp houdt geen rekening met schrikkelseconden — elke minuut wordt geteld als 60 seconden, hoewel de Internationale Aardrotatiedienst soms een extra seconde toevoegt om de atoomtijd te corrigeren.

Unix-tijdperk: waarom 1970?

De keuze voor 1 januari 1970 hangt samen met de ontwikkelingsgeschiedenis van het Unix-besturingssysteem. Ontwikkelaars Ken Thompson en Dennis Ritchie kozen deze datum als een eenvoudig en rond beginpunt — het was vroeg genoeg om alle mogelijke datums te dekken en tegelijkertijd laat genoeg om de tijd in een 32-bits ondertekend geheel getal te kunnen opslaan. Aanvankelijk werd tijd gemeten in zestigsten van een seconde, daarna in ticks (1/60 seconde), en pas in de zevende editie van Unix (V7, 1979) stabiliseerde het formaat zich als een geheel aantal seconden. Volgens The Open Group Base Specifications (Issue 8, 2024) zijn POSIX-compatibele systemen verplicht dit formaat te ondersteunen.

Hoe werkt Unix Timestamp

Het werkingsprincipe van Unix Timestamp is gebaseerd op een eenvoudige teller: elke verstreken dag voegt 86 400 seconden toe aan de waarde. Bijvoorbeeld, timestamp 1 720 000 000 komt overeen met een datum midden 2024 — exacte conversie kan worden gedaan door te delen door het aantal seconden in een dag, uur en minuut. Deze benadering maakt timestamp ideaal voor machinale opslag: het is een geheel getal dat 4 bytes (32-bits int) of 8 bytes (64-bits long) beslaat en directe vergelijking ondersteunt — grotere timestamp = latere datum.

Wiskunde van conversie

Eén dag = 86 400 seconden (24 x 60 x 60). Eén uur = 3600 seconden. Om timestamp naar datum te converteren, moet u achtereenvolgens het aantal dagen, uren, minuten en seconden berekenen vanaf het begin van het tijdperk. Omgekeerde conversie — zet de datum om in dagen sinds 1970-01-01, vermenigvuldig dan met 86 400 en voeg de verschuiving ten opzichte van UTC toe. In Java en Kotlin zijn deze berekeningen al geïmplementeerd in de standaardklassen java.time.Instant en java.util.Date, wat de ontwikkelaar van handmatige berekeningen bevrijdt.

        // Verkrijg Unix Timestamp in seconden
val seconds = System.currentTimeMillis() / 1000

// Converteer timestamp naar datum via java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Omgekeerd: datum naar timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Conversie van Unix Timestamp naar datum en terug

Conversie van Unix Timestamp naar een voor mensen leesbare datum is een van de meest voorkomende bewerkingen in mobiele ontwikkeling. Op Android zijn verschillende conversiemethoden beschikbaar afhankelijk van de minimale API-versie: voor API 26+ wordt java.time.Instant aanbevolen, voor oudere versies wordt java.util.Date en java.text.SimpleDateFormat gebruikt. Het is belangrijk te onthouden dat Android en JVM standaard milliseconden gebruiken, geen seconden — als de timestamp van de server in seconden is ontvangen, moet deze met 1000 worden vermenigvuldigd voordat deze aan standaardconstructors wordt doorgegeven.

Conversie met tijdzone van de gebruiker

Een van de belangrijkste voordelen van Unix Timestamp is de onafhankelijkheid van locatie. De server retourneert altijd de timestamp in UTC, en conversie naar lokale datum en tijd vindt plaats aan de clientzijde. In Kotlin wordt hiervoor ZonedDateTime met de juiste ZoneId gebruikt — systeem of door de gebruiker gekozen. Als de applicatie tijd in verschillende zones weergeeft (bijvoorbeeld voor reizigers), elimineert timestamp de noodzaak om de tijdzone van de server door te geven — één tijdstempel is voldoende.

// Conversie met tijdzone van gebruiker
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))
}

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

Het probleem van 2038

Het probleem van 2038 (Year 2038 Problem, Y2K38) — is een fundamentele beperking van 32-bits ondertekende gehele getallen voor het opslaan van Unix Timestamp. De maximale waarde van een 32-bits signed int is 2 147 483 647, wat overeenkomt met 19 januari 2038 om 03:14:07 UTC. Na deze datum raakt de waarde overvol en verandert in een negatief getal, wat storingen veroorzaakt in systemen die 32-bits time_t gebruiken. Het probleem is vergelijkbaar met de bekende Y2K, maar treft vooral embedded systemen, oudere Android-versies en IoT-apparaten met 32-bits architectuur.

Omvang van het probleem

Volgens Linux Foundation (2025) gebruikt ongeveer 15% van de Linux-apparaten in de industriële en IoT-sector nog steeds 32-bits compilaties. Voor Android-apparaten is het risico lager — de meeste moderne smartphones werken op 64-bits processors (ARM64), maar oudere modellen met Android 4.x en lager kunnen 32-bits time_t gebruiken. De oplossing — migratie naar 64-bits time_t, die veilig is voor 292 miljard jaar. Sinds Android 5.0 (API 21) gebruiken alle apparaten 64-bits tijd op kernelniveau. Mobiele app-ontwikkelaars hoeven alleen de timestamp in het type Long (64-bits) op te slaan om het probleem op applicatieniveau te voorkomen.

Werken met Unix Timestamp in Android

In Android-ontwikkeling is correct werken met Unix Timestamp cruciaal voor gegevenssynchronisatie, weergave van berichtontvangsttijden, berekening van time-outs en planning van meldingen. De systeemaanroep System.currentTimeMillis() retourneert de huidige tijd in milliseconden sinds het Unix-tijdperk — dit is de meest nauwkeurige tijdbron die op het apparaat beschikbaar is. Voor netwerkverzoeken wordt meestal Unix Timestamp in seconden gebruikt, omdat de meeste REST API’s en databases precies met seconden werken.

Aanbevolen praktijken

Gebruik nooit System.currentTimeMillis() voor het meten van intervallen — hiervoor bestaat System.nanoTime(), die monotoon is en niet afhankelijk van klokwijzigingen door de gebruiker. Voor tijdweergave, bewaar de timestamp altijd in UTC en converteer naar de lokale tijdzone aan de interfacekant. Bij het werken met databases (SQLite, Room) gebruikt u het type INTEGER en bewaart u de timestamp in seconden — dit beslaat 8 bytes (Long) en ondersteunt native SQL-sortering. Voor serialisatie in JSON wordt aanbevolen de timestamp als getal (Long) te versturen, niet als string — dit is compacter en sneller te parsen.

// Correcte meting van uitvoeringstijd
val start = System.nanoTime()
// ... bewerking ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

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

Verwerking van tijd van de server

Bij het ontvangen van Unix Timestamp van de server, controleer altijd de meeteenheid: sommige API’s retourneren milliseconden (JavaScript-compatibel), andere — seconden (POSIX-standaard). De afspraak over eenheden moet in de API-documentatie worden vastgelegd. In het serverantwoord kan de timestamp worden verzonden als Long (JSON-getal) of String (ISO 8601). Voor foutopsporing, voeg een hulpfunctie toe die de timestamp in een voor mensen leesbaar formaat weergeeft — dit vereenvoudigt de controle van de juistheid van tijdstempels tijdens de ontwikkeling.

Opslag van tijdstempels in databases

De keuze van het opslagformaat voor tijd in de database heeft directe invloed op de prestaties van queries, codecomplexiteit en correctheid van werken met tijdzones. Unix Timestamp — het meest efficiënte formaat voor relationele databases: het wordt opgeslagen als een geheel getal (4 of 8 bytes), ondersteunt indexering en snelle sortering. In tegenstelling tot ISO 8601-strings, vereist timestamp geen parsing bij sortering en neemt het minder ruimte in beslag in de index. Voor Room en SQLite wordt aanbevolen de timestamp in het type INTEGER op te slaan en een index op de tijdkolom te gebruiken.

Aanbevelingen voor mobiele projecten

Voor Android-applicaties met de Room-bibliotheek wordt aanbevolen de timestamp op te slaan als Long (64-bits) en TypeConverter te gebruiken voor automatische conversie tussen Long en Date of Instant. Gebruik bij databasequery’s vergelijkingsoperatoren (>, <, BETWEEN) — deze werken native met numerieke typen. Voor het cachen van gegevens die sortering op tijd vereisen (bijvoorbeeld een berichtenlijst), maak dan verplicht een index aan op de timestamp-kolom — dit versnelt queries met ORDER BY met verschillende orden van grootte bij grote hoeveelheden gegevens.