Volledige gids voor Unix timestamps: seconden/milliseconden/microseconden omrekenen en aanbevolen aanpak voor tijdzones

Unix timestamps drukken tijd uit als “de verstreken tijd sinds de Unix epoch (1 januari 1970, 00:00:00 UTC).” Meer dan 95% van de webservers en 90% van de databasesystemen wereldwijd gebruikt deze weergave intern. Deze gids behandelt precisieverschillen, implementaties in programmeertalen, tijdzone-afhandeling en overwegingen rond zomertijd.

Oorsprong en definitie van de Unix timestamp

De Unix epoch begon op 1 januari 1970, 00:00:00 UTC. Unix timestamp 0 correspondeert met dit moment, terwijl 1262304000 overeenkomt met 2010-01-01 00:00:00 UTC. Het systeem negeert standaard de effecten van schrikkelseconden.

Oorspronkelijk opgeslagen als 32-bits signed integers, wat leidde tot het jaar-2038-probleem — de maximale waarde loopt over op 19 januari 2038, 03:14:07 UTC. Moderne systemen gebruiken 64-bits integers, zodat er veel langere tijdperiodes kunnen worden weergegeven.

Precisieverschillen

Eenheid	Aantal per seconde	Cijfers	Typische toepassingen
Seconden (s)	1	10	Traditionele Unix/Linux-systemen
Milliseconden (ms)	1.000	13	JavaScript, Java, logging
Microseconden (μs)	1.000.000	16	Distributed tracing, databases
Nanoseconden (ns)	1.000.000.000	19	Go-taal, prestatieanalyse

Praktische vuistregel: timestamps van 10 cijfers stellen doorgaans seconden voor, 13 cijfers milliseconden, 16 cijfers microseconden en 19 cijfers nanoseconden.

JavaScript-timestamps

JavaScript gebruikt standaard milliseconden. De Date()-constructor gaat ervan uit dat ingevoerde getallen milliseconden zijn — voor timestamps op secondeniveau vermenigvuldig je die met 1000.

// Get current Unix timestamp (in milliseconds)
const timestampMs = Date.now();
console.log(timestampMs);  // Example output: 1692268800123

// For second-level timestamps, divide milliseconds by 1000 and round down
const timestampSec = Math.floor(Date.now() / 1000);
console.log(timestampSec); // Example output: 1692268800

// Convert Unix timestamp back to Date object
let ts = 1692268800;
let date = new Date(ts * 1000);
console.log(date.toISOString()); // "2023-08-17T16:00:00.000Z"

Python-timestamps

Python’s time.time() geeft timestamps op secondeniveau terug als drijvende-kommagetallen:

import time
from datetime import datetime, timezone

# Get current Unix timestamp (seconds, float)
now_sec = time.time()
print(now_sec)  # Example output: 1692268800.123456

# Get milliseconds (integer)
now_millis = int(time.time() * 1000)
print(now_millis)  # Example: 1692268800123

# Get nanoseconds (Python 3.7+)
now_nanos = time.time_ns()
print(now_nanos)  # Example: 1692268800123456789

# Convert to datetime
ts = 1692268800
dt_local = datetime.fromtimestamp(ts)
dt_utc = datetime.fromtimestamp(ts, timezone.utc)
print(dt_local.strftime("%Y-%m-%d %H:%M:%S"))  # Local time
print(dt_utc.strftime("%Y-%m-%d %H:%M:%S"))    # UTC time

Go-timestamps

De time-bibliotheek van Go biedt meerdere precisieniveaus:

package main

import (
    "fmt"
    "time"
)

func main() {
    // Get current Unix timestamp
    sec := time.Now().Unix()        // Seconds
    msec := time.Now().UnixMilli()  // Milliseconds (Go 1.17+)
    nsec := time.Now().UnixNano()   // Nanoseconds

    fmt.Println(sec)   // Example: 1692268800
    fmt.Println(msec)  // Example: 1692268800123
    fmt.Println(nsec)  // Example: 1692268800123456789

    // Convert timestamp to Time object
    t := time.Unix(sec, 0)
    fmt.Println(t.UTC())
    fmt.Println(t)
}

Veelgemaakte fouten en aanbevolen aanpak

Voorbeeldfout: onduidelijke eenheden

// ✗ Fout: onduidelijke timestamp-eenheid
const timestamp = 1692268800;
const date = new Date(timestamp); // Fout: wordt als milliseconden behandeld, toont 1970

// ✓ Correct: eenheden expliciet aangeven
const timestampSec = 1692268800;
const timestampMs = 1692268800000;
const dateFromSec = new Date(timestampSec * 1000);

Aanbevolen aanpak voor veldnamen

log_entry = {
    "timestamp_ms": 1692268800123,           # Millisecond-level
    "timestamp_iso": "2023-08-17T16:00:00Z", # ISO 8601 UTC
    "event_type": "user_login",
    "user_id": 12345
}

Valkuilen bij tijdzone-afhandeling

Er zijn vier veelvoorkomende valkuilen bij het werken met tijdzones:

Lokale tijd en UTC door elkaar halen — Unix timestamps zijn altijd UTC-gebaseerd; zet ze pas om naar lokale tijd bij weergave
Geen tijdzone-informatie opslaan — Dit veroorzaakt dubbelzinnigheid; sla altijd UTC op of voeg de offset toe
Tijdzone-inconsistenties tussen systemen — Alle systemen moeten dezelfde tijdzonestandaard gebruiken (aanbevolen: UTC)
Handmatig DST-offsets berekenen — Vertrouw op ingebouwde bibliotheken, niet op hardgecodeerde waarden

De aanbevolen aanpak: sla altijd op in UTC, geef weer in lokale tijd. Gebruik UTC of Unix timestamps bij opslag en overdracht om consistentie te garanderen; formatteer op basis van de tijdzone van de gebruiker bij weergave.

Zomertijd (DST)

Zomertijd (DST) creëert twee problematische periodes:

Overgeslagen tijd: wanneer de zomertijd ingaat, gaat de klok vooruit. Zo springt 02:00 direct naar 03:00, waardoor 02:30 niet bestaat.
Herhaalde tijd: wanneer de zomertijd eindigt, verschijnt 01:00–01:59 twee keer, wat dubbelzinnigheid veroorzaakt.

Unix timestamps zelf blijven continu en worden niet beïnvloed door DST, maar lokale tijdconversies vereisen zorgvuldige afhandeling.

Aanbevolen aanpak voor logging, databases en API’s

Logsystemen

Gebruik een uniforme UTC-tijdzone met ISO 8601-formaat; voeg waar nodig timestamps toe op milliseconde- of microsecondenprecisie.

Databases

Geef de voorkeur aan native kalendertypen met tijdzone; gebruik BIGINT voor numerieke timestamps met een duidelijke eenheidsaanduiding in veldnamen (bijv. *_epoch_ms).

API’s

Geef formaten en eenheden expliciet op. Externe interfaces kunnen het beste ISO 8601 gebruiken (leesbaar, inclusief tijdzone); interne systemen kunnen numerieke timestamps gebruiken met gedocumenteerde eenheden.

Veelvoorkomende foutscenario’s

Fout bij het verwerken van 13-cijferige timestamps: milliseconde-timestamps die worden doorgegeven aan functies die seconden verwachten, veroorzaken overflow. Bepaal de eenheden eerst op basis van het aantal cijfers.
Onjuiste indelingen: ongeldige datums, ontbrekende tijdzones of DST-overgangspunten veroorzaken fouten bij het inlezen.
Tijdzone-offsets: afwijkingen van hele uren (±8 uur) wijzen doorgaans op een tijdzone-fout. Aanbevolen: UTC intern gebruiken.
Numerieke overflow: 32-bits systemen kampen met de 2038-limiet; geef prioriteit aan 64-bits integers.

Veelgestelde vragen

Waarom 1 januari 1970?

De ontwikkeling van het Unix-besturingssysteem begon in 1970, en het was een rond decenniumjaar — makkelijk te onthouden en te berekenen. 32-bits integers konden datums van 1970 tot 2038 weergeven, wat destijds voldoende was.

Hoe onderscheid je seconden van milliseconden?

Drie methoden: controleer het aantal cijfers (10 cijfers = seconden, 13 = milliseconden, 16 = microseconden, 19 = nanoseconden), verifieer door te verwerken en te controleren of de uitkomst redelijk is, of gebruik online conversietools.

Is het jaar-2038-probleem nog relevant?

Moderne systemen die 64-bits integers gebruiken hebben dit grotendeels opgelost. De meeste gangbare programmeertalen ondersteunen al 64-bits timestamps. Verouderde 32-bits systemen en embedded apparaten verdienen mogelijk nog aandacht.

Waarom veroorzaakt DST problemen?

Tijdsdiscontinuïteit door overgeslagen uren en tijdsherhaling door herhaalde uren zorgen voor dubbelzinnigheid bij het inlezen. Verschillende systemen hanteren verschillende strategieën voor ambigue tijden. Oplossing: gebruik UTC intern en zet pas op het moment van weergave om naar lokale tijd.

Waarom verschillen JavaScript- en Python-timestamps?

JavaScript’s Date.now() geeft milliseconden terug (13 cijfers); Python’s time.time() geeft seconden terug (drijvende komma met microsecondennauwkeurigheid). Voor conversie deel of vermenigvuldig je met 1000.

Actuele trends en toekomstverwachting

Hogere precisie: financiële handel, IoT en realtime systemen vereisen nauwkeurigheid op nanosecondenniveau
Gedistribueerde synchronisatie: NTP- en PTP-protocollen verbeteren de nauwkeurigheid
Blockchain-timestamps: cryptocurrency vereist fraudebestendige timestamps met hoge precisie
Prestatieoptimalisatie: SIMD-instructies, geheugencaching en parallelle verwerking versnellen conversies

Zelf uitproberen

Reken Unix timestamps direct om met onze Unix Timestamp Omrekenen — detecteert automatisch seconden, milliseconden en microseconden. 100% in je browser.

Werk je met PostgreSQL? Lees wat er precies in een PostgreSQL timestamp-kolom wordt opgeslagen voor meer informatie over tijdzone-valkuilen die specifiek zijn voor Postgres.

Samenvatting

Deze uitgebreide gids behandelt de essentie van Unix timestamps — van epoch-oorsprong en conversies op meerdere precisieniveaus tot implementaties in verschillende talen, tijdzone-afhandeling, DST-valkuilen en aanbevolen aanpak voor engineering in logging, databases en API-ontwerp. De belangrijkste les: sla op in UTC, geef weer in lokale tijd, en wees altijd expliciet over de eenheden van je timestamps.

Timestamps zijn slechts één onderdeel van de gereedschapskist van de ontwikkelaar. Verken meer essentiële tools voor encoderen, hashing en omrekenen via de Go Tools-catalogus.

Unix timestamp omrekenen: precisie, tijdzone & DST-gids