Een Ontwikkelaarsgids voor de Unix Timestamp Converter

Een Unix timestamp converter is een van die eenvoudige maar onmisbare tools waar je als ontwikkelaar of data-analist constant naar grijpt. Het is een handig hulpmiddel dat een lang, schijnbaar willekeurig getal vertaalt naar een datum en tijd die we daadwerkelijk kunnen begrijpen. Deze vertaling is cruciaal wanneer je door systeemlogs graaft, met API's werkt of databases doorzoekt waar tijd in dit super-efficiënte formaat wordt opgeslagen.

Wat is een Unix timestamp en waarom is het belangrijk?

Voordat je een goede converter echt kunt waarderen, moet je begrijpen wat dat getal eigenlijk is. In de kern is een Unix timestamp gewoon een doorlopende telling van seconden. Het telt het totale aantal seconden sinds 00:00:00 UTC op 1 januari 1970. Dat specifieke moment in de tijd staat bekend als de "Unix-epoch".

Waarom deze methode? Eenvoud en efficiency. Het opslaan van tijd als een enkel geheel getal is veel compacter en presteert beter dan een uitgebreide tekenreeks zoals "vrijdag 1 januari 2021 00:00:00 GMT". Dit maakt het perfect voor een paar belangrijke gebieden:

• Databaseopslag: Tijdstempels zijn klein, waardoor ze snel geïndexeerd en doorzocht kunnen worden. Dit is een grote winst voor de prestaties.
• API-belastingen: Het heen en weer sturen van een enkel getal belast de bandbreedte veel minder dan het verzenden van een volledige datumtekenreeks, wat leidt tot snellere responstijden.
• Logbestanden: Wanneer je logs van tientallen verschillende systemen verwerkt, is een uniforme, taalonafhankelijke tijdstempel een redder in nood.
• Berekeningen: Moet je weten hoelang een proces duurde? Trek gewoon de begintijdstempel af van de eindtijdstempel. Het is eenvoudige gehele getalrekenkunde.

Seconden versus milliseconden en daarbuiten

De klassieke Unix timestamp is een 10-cijferig getal dat seconden vertegenwoordigt. Maar naarmate de technologie evolueerde, groeide de behoefte aan fijnmaziger tijdsregistratie. Hier ga je verschillende lengtes van tijdstempels zien, en het is een veelvoorkomend struikelblok.

Hier is een snel overzicht van wat je in de praktijk doorgaans tegenkomt. Het verwarren van het een met het ander is een klassieke "off-by-a-thousand"-fout die tot zeer verwarrende bugs kan leiden.

Veelgebruikte Unix timestamp-formaten in één oogopslag

Eenheid	Cijfers	Typisch gebruikssituatie	Voorbeeldwaarde (voor hetzelfde moment)
Seconden	10	Standaard voor de meeste backendsystemen, databases en API's.	1609459200
Milliseconden	13	Zeer gebruikelijk in webtechnologie, met name JavaScript.	1609459200000
Microseconden	16	Gebruikt bij high-frequency trading of wetenschappelijke berekeningen.	1609459200000000

Deze formaten correct begrijpen is essentieel. Als een tool seconden verwacht en je voert er milliseconden in, krijg je een datum die duizenden jaren in de toekomst ligt. Het is een fout die we allemaal ooit hebben gemaakt!

Het bekende probleem van het jaar 2038

De elegante eenvoud van de Unix timestamp zorgde ook voor een tikkende tijdbom: het "probleem van het jaar 2038". Op oudere 32-bit systemen werden tijdstempels opgeslagen als een tekenhoudend 32-bit geheel getal. Het probleem is dat dit type geheel getal een plafond heeft – het kan geen getal bevatten groter dan 2,147,483,647.

Op 19 januari 2038, om 03:14:07 UTC zal het aantal seconden sinds de epoch die limiet overschrijden. Wanneer dat gebeurt, zal het geheel "omslaan" en een negatief getal worden. Dit zou ervoor zorgen dat kwetsbare systemen de datum interpreteren als diep in 1901, wat miljarden nog steeds aanwezige verouderde apparaten kan crashen. U kunt meer inzicht krijgen in de Unix-epoch en de impact ervan via de experts van StrongDM.

Gelukkig is dit niet iets waar de meesten van ons ons dagelijks zorgen over hoeven te maken. De overgrote meerderheid van moderne systemen is overgestapt op 64-bits gehele getallen voor tijdsregistratie. Een 64-bits geheel getal is zo enorm groot dat het nog 292 miljard jaar niet overloopt, waardoor het probleem effectief voor altijd wordt opgelost.

Toch is het een fantastisch stukje computerhistorie en een essentiële kennis als je ooit aan oude ingebedde systemen of verouderde codebases werkt. Het begrijpen van deze fundamentals maakt elke Unix-timestamp converter een veel krachtiger gereedschap in handen.

Conversies eenvoudig maken in uw browser

Hoewel het gebruik van een terminalopdracht of een stukje code werkt, is het niet altijd de snelste manier om dingen gedaan te krijgen. Soms heb je gewoon nu nu een antwoord nodig, zonder je focus te doorbreken of van venster te wisselen. Hier bewijst een goed browsergebaseerd gereedschap zijn waarde, met name een toegewijde Unix-timestamp converter die direct in uw browser woont.

Het echte magische hier is om in de flow te blijven. Stel je voor: je doorzoekt een API-respons in de ontwikkelaarshulpmiddelen van je browser en spot een timestamp. In plaats van een ander tabblad te openen of een terminal te starten, gebruik je een snelle toetsenbordcombinatie, plakt het getal en krijg je direct je antwoord. Dat is het soort naadloze workflow dat je krijgt met gereedschappen zoals ShiftShift Extensions, die een reeks handige nuttige functies verpakken in één Command Palet.

Ontvang direct antwoorden met een toetsenbordcombinatie

Het komt allemaal neer op snelheid. Met een gereedschap zoals ShiftShift opent een snelle dubbeltik op de Shift-toets (of Cmd+Shift+P op een Mac) een opdrachtbalk. Begin gewoon met typen "timestamp", en de converter verschijnt. Plak uw waarde, en u heeft direct een leesbare datum.

Zo ziet dat eruit – het Command Palet staat klaar en wacht om een timestamp direct boven uw huidige pagina te converteren.

Het beste is hoe het integreert zonder in de weg te staan. De converter is slechts één van de vele gereedschappen beschikbaar in dezelfde overlay, dus u hoeft nooit te stoppen met wat u aan het doen bent.

Deze aanpak is een redder in nood voor ontwikkelaars, testers en iedereen die praktisch in zijn browser woont. Bovendien gebeurt de conversie volledig op uw machine. Gevoelige gegevens van logs of API-respons verlaten uw computer nooit, wat een grote winst is voor de privacy.

In staat zijn om een timestamp te converteren, een rommelige JSON-blob te herformatteren en vervolgens een tijdsverschil te berekenen – allemaal vanuit dezelfde interface – is een enorme tijdbesparing. Het verandert een omslachtig, multi-gereedschapsproces in één soepele actie.

Meer dan slechts één truc

Een geweldig browser-hulpmiddel is zelden slechts één gereedschap; het maakt deel uit van een volledige gereedschapkist. U zult vaak merken dat u de timestamp converter naast andere functies gebruikt.

Bijvoorbeeld, u kunt het combineren met:

• Een JSON- of SQL-formatter om wat code op te ruimen voordat u de timestamp pakt.
• Een ingebouwde rekenmachine voor snelle berekeningen met epoch-waarden. (U kunt spelen met een vergelijkbaar gereedschap op de ShiftShift rekenmachine-pagina om te zien hoe het werkt).
• Een tekstvergelijkingsgereedschap om verschillen tussen twee API-respons te vinden, inclusief timestamps.

Al deze essentiële functies op één plek hebben, creëert een veel snellere en meer samenhangende workflow. Het gaat niet alleen om gemak – het gaat om het elimineren van al die kleine, herhaalde onderbrekingen die zich opstapelen en uw productiviteit gedurende een dag doden.

Praktische timestamp-conversies in code

Als u een ontwikkelaar bent, weet u dat het rommelen met timestamps gewoon deel uitmaakt van het werk. Maar laten we eerlijk zijn, de syntax is nooit helemaal hetzelfde van de ene programmeertaal naar de andere. Dit gedeelte is uw handige geheugensteun, vol met code-fragmenten die u direct kunt pakken en gebruiken voor de platforms waar u daadwerkelijk mee werkt. Geen oude Stack Overflow-threads meer doorzoeken – gewoon praktische voorbeelden om u op weg te helpen.

Of je nu gegevens op een webfrontend verwerkt, een Python-script schrijft, of een database bevraagt, het converteren van epoch-tijd is een fundamentele vaardigheid. We bespreken de meest voorkomende scenario's, van het omzetten van een epoch-integer naar een leesbare string en het vervolgens allemaal weer omkeren.

Tijdstempels converteren in JavaScript

Het Date-object in JavaScript is hier je belangrijkste hulpmiddel, maar het heeft een grote eigenaardigheid die ontwikkelaars continu in de war brengt: het werkt in milliseconden, niet in seconden. Dit is een klassieke bron van bugs wanneer je frontend communiceert met een backend die standaard 10-cijferige, op seconden gebaseerde tijdstempels gebruikt.

Om een standaard Unix-tijdstempel (in seconden) correct te converteren naar een Date-object, moet je het vermenigvuldigen met 1000.

// A standard 10-digit Unix timestamp (in seconds)
const unixTimestamp = 1672531200;

// Convert to milliseconds, then create a Date object
const dateObject = new Date(unixTimestamp * 1000);

// Format into a readable UTC string
// Output: Sun, 01 Jan 2023 00:00:00 GMT
console.log(dateObject.toUTCString());

Het huidige tijdstempel nodig? Date.now() geeft het in milliseconden. Onthoud simpelweg om door 1000 te delen en af te ronden voordat je een standaard 10-cijferig tijdstempel terugstuurt naar een API.

Conversies afhandelen met Python

Op de backend is Python's datetime-module een krachtpatser. Het is ongelooflijk flexibel en heeft uitstekende ondersteuning voor conversies met tijdzonebewustzijn, waardoor het een betrouwbare keuze is voor services die tijd nauwkeurig over verschillende regio's moeten afhandelen.

Hier is de eenvoudige manier om een tijdstempel te converteren met de datetime-bibliotheek:

import datetime

Een standaard 10-cijferig Unix-tijdstempel

unix_timestamp = 1672531200

Converteer het tijdstempel naar een datetime-object

datetime_obj = datetime.datetime.fromtimestamp(unix_timestamp)

Formatteer het naar een nette, menselijk leesbare tekenreeks

Output: 2023-01-01 00:00:00

print(datetime_obj.strftime('%Y-%m-%d %H:%M:%S'))
Deze eenvoudige aanpak geeft je een nette en betrouwbare manier om epoch-tijd in je Python-applicaties te beheren. En als je werkt met complexe datagestructuren zoals JSON die tijdstempels bevatten, vind je onze gids over het gebruik van een JSON-formatter mogelijk nuttig voor het debuggen.

Conversies in databases met SQL

Databases slaan tijd vaak op als Unix-tijdstempels omdat ze efficiënt zijn. Het goede nieuws is dat de meeste SQL-dialecten ingebouwde functies hebben om deze conversies direct binnen je queries af te handelen. Dit is veel efficiënter dan het ophalen van ruwe integer-tijdstempels en deze omzetten in je applicatiecode.

Het Unix-tijdstempel is bijna universeel, gebruikt in meer dan 90% van programmeertalen – van JavaScript's Date.now() tot Python's time.time() – en ondersteunt biljoenen dagelijkse bewerkingen. Het correct instellen van tijdzones is cruciaal; een solide unix timestamp converter kan meer dan 400 IANA-zones verwerken, wat helpt om fouten te voorkomen in een geschatte 62% van wereldwijde applicaties die tijdzones niet expliciet beheren. Je vindt meer details over de wereldwijde adoptie van deze hulpmiddelen op Fossa.

Voor ontwikkelaars is het vermogen om SQL te formatteren, tijdstempels te converteren en epoch-verschillen te berekenen zonder je machine te verlaten, een enorme productiviteitswinst. Deze lokale-aanpak zorgt er ook voor dat je voldoet aan moderne gegevensprivacy-normen zoals GDPR en CCPA.

MySQL-voorbeeld

In MySQL is de FROM_UNIXTIME()-functie degene die je het meest zult gebruiken. Het neemt een epoch-integer en converteert het netjes naar een standaard DATETIME-formaat.

SELECT FROM_UNIXTIME(1672531200);
-- Geeft terug: '2023-01-01 00:00:00'
Om de andere kant op te gaan – van een datumstring terug naar een epoch-tijdstempel – gebruik je simpelweg UNIX_TIMESTAMP().

SELECT UNIX_TIMESTAMP('2023-01-01 00:00:00');
-- Geeft terug: 1672531200

PostgreSQL voorbeeld

PostgreSQL gebruikt een iets andere maar even krachtige functie: to_timestamp(). Deze functie converteert een Unix-tijdstip direct naar een TIMESTAMP WITH TIME ZONE waarde.

SELECT to_timestamp(1672531200);
-- Geeft terug: 2023-01-01 00:00:00+00
Omdat het standaard al rekening houdt met tijdzones, is het een zeer robuuste keuze voor applicaties die een wereldwijd publiek bedienen waar tijdsprecisie essentieel is.

Tijdstipconversies beheersen in de terminal

Als je in de opdrachtregel werkt, is het overschakelen naar een browser of grafische interface voor een snelle tijdstipconversie een echte onderbreking van je workflow. Het doorbreekt gewoon je concentratie. Het goede nieuws is dat het niet nodig is; zowel Linux als macOS beschikken over krachtige, ingebouwde tools om deze conversies uit te voeren zonder de terminal te verlaten.

De standaardtool hiervoor is het bescheiden date commando. Het is op praktisch elk Unix-achtig systeem aanwezig, maar er is een addertje onder het gras: de syntax voor het gebruik als unix tijdstip converter verschilt tussen Linux (GNU) en macOS (BSD). Het kennen van het verschil is de sleutel om het elke keer goed te doen.

Tijdstippen converteren op Linux

Op Linux is de syntax schoon en gemakkelijk te onthouden. Je gebruikt simpelweg de -d vlag om de datum op te geven, maar je moet het systeem vertellen dat je een epoch-tijdstip geeft door er een @ symbool voor te plaatsen.

Stel dat je door logs bladert en het tijdstip 1704067200 tegenkomt. Om te zien wat dat werkelijk betekent, voer je dit uit:

date -d @1704067200

Direct krijg je een menselijk leesbare datum terug, zoals Mon Jan 1 00:00:00 UTC 2024. Je kunt de uitvoer ook opschonen met je eigen aangepaste formaat.

date -d @1704067200 +"%Y-%m-%d %H:%M:%S"

Uitvoer: 2024-01-01 00:00:00

Pro Tip: Dit commando wordt een echte krachtpatser wanneer je andere commando's erdoor pipeert. Je kunt een grep tijdstip uit een groot logbestand extraheren en het direct naar date voeren voor een directe conversie. Het verandert een meerstappen debugtaak in één elegante regel.

Conversies afhandelen op macOS

Als je nu datzelfde Linux-commando op een Mac uitvoert, geeft het een foutmelding. De BSD-versie van date die macOS gebruikt, vereist in plaats daarvan de -r vlag en heeft geen @ prefix nodig.

Zo convergeer je hetzelfde tijdstip op een Mac:

date -r 1704067200

Net als bij de Linux-versie kun je opmaakopties toevoegen om precies de gewenste uitvoer te krijgen.

date -r 1704067200 +"%Y-%m-%d %T %Z"

Uitvoer: 2024-01-01 00:00:00 UTC

Dit kleine verschil is een klassieke valkuil voor iedereen die vaak tussen Linux en macOS schakelt. Het onthouden van beide versies bespaart je later een hoop gedoe.

Zodra je deze commando's beheerst, kun je tijdstipconversies rechtstreeks verweven in je shellscripts en loganalyses. Het is een kleine vaardigheid, maar het leidt tot aanzienlijke productiviteitswinst, waardoor je in de zone blijft en gefocust op het belangrijke werk.

Veelvoorkomende valkuilen met tijdstippen en hoe ze te vermijden

Werken met Unix-tijdstippen lijkt op het oppervlak eenvoudig, maar enkele klassieke fouten kunnen leiden tot werkelijk frustrerende bugs. Deze problemen hebben de vervelende gewoonte om ver van waar de fout daadwerkelijk optrad op te duiken, waardoor ze een echte hoofdpijn zijn om te debuggen. Beschouw dit hoofdstuk als je veldgids om de meest voorkomende tijdstipvalkuilen die ik door de jaren heen heb gezien te herkennen en te vermijden.

De seconden versus milliseconden verwarring

Veruit de meest gemaakte fout is het verwarren van seconden met milliseconden. Een standaard Unix-tijdstip is een 10-cijferig geheel getal dat het aantal seconden sinds de epoch vertegenwoordigt. Maar veel systemen, vooral in de JavaScript-wereld, werken met een 13-cijferig tijdstip voor milliseconden. Wanneer een front-end applicatie een milliseconden waarde doorgeeft aan een back-end die seconden verwacht, gaat het mis.

Voor een unix timestamp convertor, ziet dat 13-cijferige getal eruit als een datum duizenden jaren in de toekomst. Dit kan stilletjes datavalidatie, planningslogica en alle historische gegevens die je probeert bij te houden, verpesten. Het is het soort subtiele gegevenscorruptie dat je misschien wekenlang niet eens opmerkt.

De Tijdzone-val

Een andere valkuil die zelfs ervaren ontwikkelaars raakt, is het omgaan met tijdzones. Per definitie is een Unix-tijdstip altijd in Coordinated Universal Time (UTC). Het vertegenwoordigt één universeel moment in de tijd, volledig onafhankelijk van locatie. De val wordt geactiveerd wanneer je dit vergeet en ervan uitgaat dat een tijdstip de lokale tijd van een gebruiker weerspiegelt.

Deze fout gebeurt meestal wanneer je een tijdstip omzet naar een leesbare datum zonder een tijdzone te specificeren. Je systeem gebruikt vaak standaard de lokale tijd van de server, wat tot chaos leidt. Een gebruiker in New York kan een tijd zien die bedoeld was voor iemand in Londen, maar die een paar uur afwijkt.

De gouden regel is eenvoudig: behandel tijdstippen in je backend altijd als UTC. Sla ze op als UTC, verwerk ze als UTC, en converteer alleen naar de lokale tijd van een gebruiker aan de voorkant, op het moment van weergave.

Probleemoplossing voor veelvoorkomende fouten bij tijdstipconversie

Wanneer het misgaat, kunnen de symptomen verwarrend zijn. Hier is een snelle referentietabel die ik heb samengesteld op basis van ervaring om je te helpen de meest voorkomende problemen snel te diagnosticeren en op te lossen.

Symptoom	Waarschijnlijke Oorzaak	Oplossing
Datum is in het jaar 52361 of een ander ver verleden.	Milliseconden vs. Seconden. Je geeft een 13-cijferig tijdstip in milliseconden door aan een functie die een 10-cijferig tijdstip in seconden verwacht.	Deel het tijdstip door 1000 voordat je het verwerkt. Controleer altijd het aantal cijfers van inkomende tijdstippen.
Tijd klopt een paar uur niet, maar de datum is correct.	Verkeerde Tijdzoneafhandeling. Het tijdstip is geconverteerd met de lokale tijd van de server in plaats van die van de gebruiker of UTC.	Zorg ervoor dat alle conversies expliciet de doeltijdzone opgeven. Converteer alleen naar lokale tijd aan de clientzijde.
De datum staat vast op 1 januari 1970.	Ongeldig of Nul Tijdstip. De waarde van het tijdstip is waarschijnlijk 0, null, of undefined.	Voeg een controle toe om ervoor te zorgen dat het tijdstip een geldig positief getal is voordat je de conversie probeert. Geef een terugvalwaarde op.
Ontvangt "Ongeldige Datum" of een NaN foutmelding.	Verkeerd Gegevenstype. Het tijdstip wordt behandeld als een tekenreeks of een ander niet-numeriek type wanneer een getal vereist is.	Parseer het tijdstip expliciet naar een geheel getal (parseInt() in JS, int() in Python) voordat je het in datiefuncties gebruikt.

Onthoud, een snelle controle van de invoer kan je uren debuggen besparen.

Ambiguïteit vermijden met standaardformaten

Het vertrouwen op rauwe integer-tijdstippen wanneer je gegevens tussen systemen doorgeeft, kan een recept voor verwarring zijn. Daarom is het standaardiseren op een universeel tekenreekstype zoals ISO 8601 (2022-05-17T12:00:00Z) zo'n geweldige verdedigende zet. Het converteren van Unix-tijdstippen (bijv. 1652905200) naar een duidelijk, zelfdocumenterend formaat zoals dit helpt fouten te voorkomen in naar schatting 37% van de API-aanroepen over tijdzones heen.

Gezien het feit dat 72% van de Fortune 500-bedrijven Unix-tijdstippen gebruiken voor loganalyse, waar een enkele fout meer dan $10,000 per uur aan downtime kan kosten, is precisie alles. Je kunt meer lezen over hoe epochtijd in verschillende sectoren wordt gebruikt op EpochConverter.

Voor degenen die databases beheren, is consistente tijdstipafhandeling net zo cruciaal. Als je merkt dat je vaak worstelt met verschillende tijdstipformaten in je database, kan onze gids over het gebruik van een krachtige SQL-formatter je helpen je queries schoon en voorspelbaar te houden.

Deze beslisboom helpt je het juiste commando voor je besturingssysteem te kiezen en syntaxfouten te voorkomen wanneer je een snelle conversie nodig hebt.

Het stroomdiagram hierboven toont duidelijk het cruciale syntactische verschil tussen het date commando op Linux (-d @...) en macOS (-r ...)—een veelvoorkomende valkuil voor ontwikkelaars die in verschillende omgevingen werken.

Om je code foutbestendig te maken, voer je altijd controles uit om de lengte van een inkomend tijdstempel te valideren. Een eenvoudige functie die controleert op een 10-cijferige (seconden) of 13-cijferige (milliseconden) waarde kan deze fouten opvangen voordat ze de logica van je applicatie ooit kunnen vergiftigen.

Veelgestelde vragen over Unix-tijdstempels

Zodra je de Unix-tijdstempels onder de knie hebt, komen er bijna altijd een paar praktische vragen naar boven. Ik heb gezien dat deze ontwikkelaars van alle niveaus dwarszitten, dus laten we de meest voorkomende vragen die je in je dagelijkse werk tegenkomt op een rijtje zetten.

Waarom gebruiken zoveel APIs tijdstempels in plaats van ISO 8601 tekenreeksen?

Het komt echt neer op ruwe efficiëntie. Een Unix-tijdstempel is slechts één enkel getal, waardoor het ongelooflijk compact is in vergelijking met een tekenreeks als '2023-10-27T10:00:00Z'. Die kleinere omvang betekent minder gegevens om over de lijn te versturen, wat bandbreedte bespaart en API-responsies kan versnellen.

Ze zijn ook volledig taalonafhankelijk. Er is geen ambiguïteit, geen vreemde parsings eigenaardigheden en geen regionale opmaak waar je je zorgen over hoeft te maken. Voor een machine is het verwerken van getallen altijd sneller dan het parsen van tekenreeksen, dus elke datum berekening—zoals het uitrekenen van de tijd tussen twee gebeurtenissen—is computationeel goedkoper. Voor prestatiegevoelige systemen is die eenvoud een enorme winst.

Wat is de juiste manier om met tijdzones om te gaan?

Dit is de grote. Hier is de gouden regel: Een Unix-tijdstempel is altijd, altijd in UTC. Het heeft geen concept van een tijdzone ingebouwd. Het is gewoon een ruwe telling van seconden sinds het epoch.

Tijdzones doen er alleen toe als je dat tijdstempel aan een mens moet tonen.

Mijn advies? Houd aan UTC voor alles aan de backend. Sla het als een UTC-tijdstempel op in je database, geef het door via je APIs in UTC, en voer al je server-side logica uit in UTC. Het enige moment dat je het naar een lokale tijdzone moet omzetten is aan de front-end, vlak voordat je het aan de gebruiker toont. Deze ene praktijk zal je behoeden voor een heel universum aan tijdzone- en zomertijd-bugs.

Moet ik me nog zorgen maken over het jaar 2038-probleem?

Voor de meeste nieuwe projecten, waarschijnlijk niet. Het "jaar 2038-probleem" is een overblijfsel van oudere systemen die een 32-bits signed integer gebruikten om het tijdstempel op te slaan. Zodra dat getal te groot wordt, slaat het over en wordt het negatief, waardoor datums teruggaan naar 1901.

Gelukkig zijn bijna alle moderne systemen—van besturingssystemen tot databases—al lang overgestapt op 64-bits integers. Dit verplaatst het probleem zo ver naar de toekomst (miljarden jaren eigenlijk) dat het voor ons geen praktische kwestie meer is.

Dat gezegd hebbende, als je een legacy-systeem onderhoudt of werkt met embedded hardware (denk aan IoT-apparaten), is het zeker iets om rekening mee te houden. Weet altijd op welke architectuur je bouwt.

Hoe kan ik snel een tijdstempel in Excel of Google Sheets converteren?

Hiervoor hoef je je gegevens niet naar een aparte Unix-tijdstempel converter te halen. Een eenvoudige formule volstaat. Neem aan dat je tijdstempel in cel A1 staat:

• Voor tijdstempels in seconden (10 cijfers): =A1 / 86400 + DATE(1970,1,1)
• Voor tijdstempels in milliseconden (13 cijfers): =A1 / 86400000 + DATE(1970,1,1)

Stop die formule er gewoon in en formatteer de cel vervolgens als "Datum" of "Datum Tijd". Het is een redder in nood wanneer je snel data-exporten analyseert en je je workflow niet wilt onderbreken.

---

Moe van het constant wisselen tussen je editor, de opdrachtregel en een dozijn browsertabs voor simpele taken? De ShiftShift Extensions suite biedt een krachtige Unix-tijdstempel converter, JSON-formatter, SQL-verfraaier en meer direct in je browser. Alles wat je nodig hebt, is slechts een sneltoets verwijderd.

Haal ShiftShift Extensions en vereenvoudig je workflow vandaag nog op https://shiftshift.app