Unix Timestamps in logbestanden — hoe je ze leest en debugt
Als iets om 2 uur 's nachts in productie kapot gaat, pak je eerst de logbestanden. En het eerste obstakel is meestal een muur van Unix timestamps — getallen van 10 cijfers die je exact vertellen wanneer elke gebeurtenis plaatsvond, als je ze maar kon lezen. 1744070400 is nauwkeurig, ondubbelzinnig, en volkomen ondoorzichtig totdat je het converteert.
De Unix Timestamp Converter zet een raw timestamp direct om in een leesbare datum. Dit artikel laat zien hoe timestamps in logboeken verschijnen, hoe je ze efficiënt converteert en correleert, en waar timestamp-gerelateerde bugs zich graag verschuilen tijdens het debuggen.
Waarom logbestanden Unix Timestamps gebruiken
Leesbare datumnotaties — "7 april 2026 14:32:05 UTC+2" — zijn handig voor mensen maar verschrikkelijk voor machines. Ze verschillen per taalregio, vereisen timezone-parsing, kunnen niet direct als getallen vergeleken worden, en nemen meer opslagruimte in dan een gewoon getal.
Unix timestamps lossen al deze problemen op. Een timestamp als 1744070400 is:
- Ondubbelzinnig — geen locale, geen formaatvar iatie
- Timezone-neutraal — altijd op basis van UTC
- Sorteerbaar — hoger getal = later moment, dus
ORDER BY timestampwerkt correct - Geschikt voor rekenen — trek twee timestamps af en je krijgt verstreken seconden
De meeste logsystemen (syslog, applicatielogboeken, databaselogboeken, CDN-toegangslogboeken) gebruiken standaard UTC Unix timestamps om deze redenen. De leesbaarheid wordt ingeruild voor nauwkeurigheid en draagbaarheid.
Een logbestand-timestamp converteren
De snelste manier is de timestamp in de Unix Timestamp Converter plakken. Het herkent automatisch seconden versus milliseconden en toont direct de UTC-datum en -tijd.
Voor snelle conversies zonder de terminal te verlaten:
Linux/Mac (bash): `bash date -d @1744070400 # Linux date -r 1744070400 # macOS `
Python: `python import datetime datetime.datetime.fromtimestamp(1744070400, tz=datetime.timezone.utc)
datetime(2026, 4, 7, 16, 0, tzinfo=timezone.utc)
**JavaScript (browser console of Node):**new Date(1744070400 * 1000).toISOString() // "2026-04-07T16:00:00.000Z" `
Let op de * 1000 in JavaScript — Date werkt in milliseconden, dus een timestamp in seconden moet voordat je het in new Date() passeert vermenigvuldigd worden. Dit vergeten is een veelvoorkomende oorzaak van "timestamp in het jaar 2527"-bugs.
Milliseconde-timestamps in logbestanden lezen
Sommige systemen loggen in milliseconden in plaats van seconden. Node.js-applicaties, Java-systemen die System.currentTimeMillis() gebruiken, en veel JavaScript-gebaseerde backends produceren 13-cijferige timestamps als 1744070400000.
De Unix Timestamp Converter herkent het format automatisch op basis van het aantal cijfers. Maar in de terminal:
# Milliseconden eerst naar seconden, dan converteren
echo $((1744070400000 / 1000)) | xargs date -d @ # LinuxOf in Python: `python datetime.datetime.fromtimestamp(1744070400000 / 1000, tz=datetime.timezone.utc) `
Snelle controle: is de timestamp 13 cijfers, dan gaat het vrijwel zeker om milliseconden. 10 cijfers betekent seconden. 16 cijfers betekent microseconden (veel voorkomen in PostgreSQL). 19 cijfers betekent nanoseconden (sommige Java- en Rust-systemen).
Timestamps over meerdere logbronnen heen correleren
Een van de moeilijkste onderdelen van het debuggen van gedistribueerde systemen is het correleren van gebeurtenissen over meerdere services die onafhankelijk loggen. Als je webserver-logbestand een 500-fout toont bij timestamp 1744070412 en je databaselogbestand een verbindingstimeout bij 1744070410, dan liggen die twee ereignissen 2 seconden uit elkaar — duidelijk gerelateerd.
Zonder Unix timestamps is deze correlatie lastig. Als de webserver in UTC+2 logt en de database in UTC-5, vereist handmatig afstemmen van de tijden dat je de offset kent en mentaal rekent. Met Unix timestamps staan beide logboeken op dezelfde schaal en trek je direct af.
Praktische werkwijze: 1. Bepaal het geschatte tijdsbereik van het incident op basis van gebruikersmeldingen of monitorialerts 2. Zet het bereik om naar Unix timestamps (met de Unix Timestamp Converter of date -d "2026-04-07 16:00:00 UTC" +%s) 3. Filter elk logbestand op dat timestampbereik: awk '$1 >= 1744070400 && $1 <= 1744070460' access.log 4. Sorteer de gecombineerde output op timestamp om een samengevoegde chronologische lijn te maken
Stap 4 is waar Unix timestamps echt hun waarde bewijzen — je kunt sort -n op de timestamp-kolom toepassen over bestanden van verschillende systemen heen en krijgt een chronologisch nauwkeurig samengevoegd overzicht.
Veelvoorkomende timestamp-bugs om op uit te kijken bij debuggen
Mismatch seconden/milliseconden. Een timestamp opgeslagen als milliseconden maar gelezen als seconden levert een datum in het jaar 2527 of dergelijke op. Een timestamp opgeslagen als seconden maar onnodig vermenigvuldigd met 1000 levert een datum in 1970 op. Beide zijn duidelijk wanneer je de waarde converteert, daarom is vroeg converteren bij debuggen waardevol.
Lokale tijd in plaats van UTC. Als een logbestand 1744077600 toont en je verwachtte 1744070400 voor dezelfde ereignis, is het verschil 7200 seconden — precies 2 uur. Dat is een timezone-offset. Sommige systemen loggen in lokale tijd in plaats van UTC, wat cross-system correlatie breekt. Bevestig altijd welke timezone een logsysteem gebruikt voordat je vermeldingen correleert.
Klokafwijking tussen servers. Gedistribueerde systemen met niet-gesynchroniseerde klokken produceren logboeken waar de timestamps niet de werkelijke volgorde van ereignissen weerspiegelen. Als server A een ereignis toont op 1744070400 en server B een causaal latere ereignis op 1744070398, loopt de klok van server B 2 seconden achter. NTP-synchronisatie voorkomt dit, maar wordt niet altijd perfect onderhouden. Bij het debuggen van race conditions of causality-problemen in gedistribueerde systemen loont het klokafwijking te checken.
Epoch opgeslagen als string. Sommige systemen loggen timestamps als string-representaties van het getal: "1744070400". Dit ziet er in veel logweergaven identiek uit aan het getal maar kan sort- of vergelijkingsproblemen veroorzaken als het niet correct geparseeerd wordt. JSON-logboeken serialiseren getallen soms als strings.
Afgekapte timestamps. Een logbericht met 174407040 (9 cijfers) in plaats van 1744070400 (10 cijfers) is afgekapt — waarschijnlijk een format- of bufferfout. De 9-cijferige waarde omgezet geeft september 2025 in plaats van april 2026.
Logbestanden filteren op tijdsbereik met Unix Timestamps
Als je het timestamp-bereik voor een tijdvenster kent, wordt logfiltering nauwkeurig:
# Unix timestamp voor een specifiek UTC-moment ophalen
date -d "2026-04-07 16:00:00 UTC" +%s # → 1744070400
date -d "2026-04-07 16:05:00 UTC" +%s # → 1744070700
# nginx-toegangslogbestand filteren (eerste veld is timestamp)
awk '$1 >= 1744070400 && $1 <= 1744070700' /var/log/nginx/access.log
# Met grep filteren als timestamp op vaste positie staat
grep -E "^174407(04|05|06|07)" /var/log/app.logVoor JSON-logboeken is jq duidelijker: `bash cat app.log | jq 'select(.timestamp >= 1744070400 and .timestamp <= 1744070700)' `
De tool Days Between Dates is nuttig wanneer je het timestamp-bereik voor een hele dag of meerdere dagen nodig hebt — zet de start- en einddatum om naar timestamps en gebruik die als filtergrenzen.
Een mentaal model voor timestamp-grootten opbouwen
Nadat je een paar incidenten met Unix timestamps hebt gedebugged, krijg je intuïtie voor de grootten. Per 2026:
- Huidige timestamps liggen in het bereik 1,74–1,75 miljard
- Één uur = 3.600 seconden (4 cijfers)
- Één dag = 86.400 seconden (5 cijfers)
- Één week = 604.800 seconden (6 cijfers)
- Één jaar ≈ 31.557.600 seconden (8 cijfers)
Dus als twee logvermeldingen met 86 seconden verschillen, liggen ze ongeveer 1,5 minuut uit elkaar. Als ze met 3.600 verschillen, precies één uur. Als ze met 604.800 verschillen, precies één week. Deze ronde getallen zijn het waard om te onthouden — ze maken mentaal rekenen met timestamps veel sneller tijdens een actief incident.
Voor elke conversie die je niet uit je hoofd weet, is de Unix Timestamp Converter het snelste pad van raw getal naar leesbare datum en terug.
