Een Unix-timestampconverter is een van die eenvoudige maar onmisbare tools waar je als ontwikkelaar of data-analist constant naar grijpt. Het is een handige tool die een lange, schijnbaar willekeurige getal omzet in een datum en tijd die we daadwerkelijk kunnen begrijpen. Deze vertaling is cruciaal wanneer je door systeemlogboeken graaft, werkt met API's of databases ondervraagt waar tijd in dit superefficiënte formaat is opgeslagen.

Wat is een Unix-timestamp en waarom is het belangrijk

Voordat je echt kunt waarderen wat een goede converter is, moet je begrijpen wat dat getal eigenlijk is. In wezen is een Unix-timestamp gewoon een lopende telling van seconden. Het houdt het totale aantal seconden bij die zijn verstreken 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 efficiëntie. Tijd opslaan als een enkel geheel getal is veel compacter en efficiënter dan een uitgebreide string zoals "vrijdag 1 januari 2021 00:00:00 GMT". Dit maakt het perfect voor een paar belangrijke gebieden:

• Database-opslag: Timestamps zijn klein, waardoor ze snel te indexeren en te ondervragen zijn. Dit is een enorme winst voor de prestaties.
• API-payloads: Het verzenden van een enkel getal heen en weer is veel lichter voor de bandbreedte dan het verzenden van een volledige datumstring, wat leidt tot snellere responstijden.
• Logbestanden: Wanneer je logs van tientallen verschillende systemen aan het parseren bent, is het hebben van een uniforme, taalagnostische timestamp een levensredder.
• Berekeningen: Wil je weten hoe lang een proces heeft geduurd? Trek gewoon de starttimestamp af van de eindtimestamp. Het is eenvoudige gehele getallen wiskunde.

Seconden versus milliseconden en verder

De klassieke Unix-timestamp is een 10-cijferig getal dat seconden vertegenwoordigt. Maar naarmate de technologie zich ontwikkelde, groeide de behoefte aan meer gedetailleerde tijdregistratie. Dit is waar je verschillende lengtes van timestamps begint te zien, en het is een veelvoorkomende struikelblok.

Hier is een snelle samenvatting van wat je meestal tegenkomt in het wild. Het verwarren van de ene met de andere is een klassieke "off-by-a-thousand" fout die kan leiden tot zeer verwarrende bugs.

Veelvoorkomende Unix-timestampformaten in een oogopslag

Eenheid	Cijfers	Typische gebruiksgeval	Voorbeeldwaarde (voor hetzelfde moment)
Seconden	10	Standaard voor de meeste backend-systemen, databases en API's.	1609459200
Milliseconden	13	Zeer gebruikelijk in webtechnologie, vooral JavaScript.	1609459200000
Microseconden	16	Gebruikt in high-frequency trading of wetenschappelijk rekenen.	1609459200000000

Deze formaten goed begrijpen is essentieel. Als een tool seconden verwacht en je geeft het milliseconden, krijg je een datum die duizenden jaren in de toekomst ligt. Het is een fout die we allemaal op een bepaald moment hebben gemaakt!

Het beroemde probleem van het jaar 2038

De elegante eenvoud van de Unix-timestamp heeft ook een tikkende tijdbom gecreëerd: het "probleem van het jaar 2038." Op oudere 32-bits systemen werden timestamps opgeslagen als een ondertekend 32-bits geheel getal. Het probleem is dat dit type geheel getal een plafond heeft - het kan geen getal groter dan 2.147.483.647 vasthouden.

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 getal "omsluiten" en een negatief getal worden. Dit zou kwetsbare systemen ertoe kunnen brengen de datum te interpreteren als zijnde terug in 1901, wat miljarden legacy-apparaten die nog steeds in gebruik zijn, zou kunnen laten crashen. Je kunt meer inzichten over de Unix-epoch en de impact ervan krijgen van de experts bij 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 tijdregistratie. Een 64-bits geheel getal is zo enorm dat het niet zal overlopen voor nog eens 292 miljard jaar, wat het probleem effectief oplost.

Toch is het een fantastisch stuk computerhistorie en een cruciaal stuk kennis als je ooit aan oudere embedded systemen of legacy-codebases werkt. Het begrijpen van deze fundamenten maakt elke Unix-timestampconverter een veel krachtiger hulpmiddel in jouw handen.

Conversies moeiteloos maken in je browser

Hoewel het gebruik van een terminalopdracht of een codefragment werkt, is het niet altijd de snelste manier om dingen gedaan te krijgen. Soms heb je gewoon een antwoord nu nodig, zonder je focus te verbreken of vensters te wisselen. Dit is waar een goede browsergebaseerde tool echt zijn waarde bewijst, vooral een speciale Unix-timestampconverter die direct in je browser zit.

De echte magie hier draait om het behouden van de flow. Stel je dit voor: je bent aan het graven door een API-respons in de ontwikkelaarstools van je browser en ziet een timestamp. In plaats van een nieuw tabblad te openen of een terminal te starten, druk je op een snelle sneltoets, plak je het nummer en krijg je onmiddellijk je antwoord. Dat is het soort naadloze workflow dat je krijgt met tools zoals ShiftShift Extensions, die een aantal handige utilities in één Command Palette bundelen.

Krijg onmiddellijke antwoorden met een sneltoets

Het draait allemaal om snelheid. Met een tool zoals ShiftShift opent een snelle dubbelklik op de Shift-toets (of Cmd+Shift+P op een Mac) een commando balk. Begin gewoon met typen "timestamp," en de converter verschijnt. Plak je waarde, en je hebt meteen een leesbare datum.

Hier is hoe dat eruitziet - de Command Palette is klaar en wacht om een timestamp direct boven je huidige pagina te converteren.

Het beste is hoe het integreert zonder in de weg te zitten. De converter is slechts een van de vele tools die beschikbaar zijn in dezelfde overlay, zodat je nooit hoeft te stoppen met wat je aan het doen bent.

Deze aanpak is een levensredder voor ontwikkelaars, testers en iedereen die praktisch in hun browser leeft. Bovendien gebeurt de conversie volledig op jouw machine. Gevoelige gegevens uit logs of API-responsen verlaten nooit je computer, wat een enorme winst voor privacy is.

In staat zijn om een timestamp te converteren, een rommelige JSON-blob opnieuw te formatteren en vervolgens een tijdsverschil te berekenen - allemaal vanuit dezelfde interface - is een enorme tijdsbesparing. Het verandert een onhandig, multi-tool proces in een enkele, soepele actie.

Meer dan alleen een eentrick pony

Een geweldige utility in de browser is zelden slechts een enkele tool; het is onderdeel van een hele toolkit. Je zult jezelf vaak de timestampconverter zien gebruiken naast andere functies.

Bijvoorbeeld, je zou het kunnen combineren met:

• Een JSON- of SQL-opmaaktool om wat code op te schonen voordat je de timestamp eruit haalt.
• Een ingebouwde calculator voor het doen van snelle berekeningen op epoch-waarden. (Je kunt met een vergelijkbare tool spelen op de ShiftShift-calculatorpagina om te zien hoe het werkt).
• Een tekstvergelijkingstool om verschillen tussen twee API-responsen te spotten, timestamps inbegrepen.

Het hebben van al deze essentiële tools op één plek creëert een veel snellere en coherente workflow. Het gaat niet alleen om gemak - het gaat om het elimineren van al die kleine, repetitieve onderbrekingen die zich opstapelen en je productiviteit gedurende de dag doden.

Praktische timestampconversies in code

Als je een ontwikkelaar bent, weet je dat het werken met timestamps gewoon deel uitmaakt van de job. Maar laten we eerlijk zijn, de syntaxis is nooit helemaal hetzelfde van de ene taal naar de andere. Deze sectie is je handige spiekbriefje, vol met codefragmenten die je meteen kunt pakken en gebruiken voor de platforms waar je daadwerkelijk op werkt. Geen gedoe meer met het doorzoeken van oude Stack Overflow-threads - gewoon praktische voorbeelden om je op weg te helpen.

Of je nu gegevens beheert op een webfrontend, een Python-script schrijft of een database ondervraagt, het converteren van epoch-tijd is een fundamentele vaardigheid. We zullen de meest voorkomende scenario's doorlopen, van het omzetten van een epoch-geheel getal in een leesbare string en dan alles in omgekeerde volgorde doen.

Timestamps converteren in JavaScript

Het Date-object van JavaScript is je belangrijkste hulpmiddel hier, maar het heeft een grote eigenaardigheid die ontwikkelaars vaak in de problemen 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 timestamps gebruikt.

Om een standaard Unix-timestamp (in seconden) correct om te zetten in een Date-object, moet je het met 1000 vermenigvuldigen.

// Een standaard 10-cijferige Unix-timestamp (in seconden)
const unixTimestamp = 1672531200;

// Omzetten naar milliseconden, maak dan een Date-object
const dateObject = new Date(unixTimestamp * 1000);

// Formatteren naar een leesbare UTC-string
// Uitvoer: zo, 01 jan 2023 00:00:00 GMT
console.log(dateObject.toUTCString());

Heb je de huidige timestamp nodig? Date.now() geeft het je in milliseconden. Vergeet niet om te delen door 1000 en naar beneden af te ronden voordat je een standaard 10-cijferige timestamp terug naar een API stuurt.

Conversies afhandelen met Python

Aan de backend is de datetime-module van Python een krachtpatser. Het is ongelooflijk flexibel en heeft fantastische ondersteuning voor tijdzone-bewuste conversies, waardoor het een betrouwbare keuze is voor services die tijd met precisie moeten verwerken in verschillende regio's.

Hier is de eenvoudige manier om een timestamp om te zetten met de datetime-bibliotheek:

import datetime

Een standaard 10-cijferige Unix-timestamp

unix_timestamp = 1672531200

Converteer de timestamp naar een datetime-object

datetime_obj = datetime.datetime.fromtimestamp(unix_timestamp)

Formatteer het naar een schone, leesbare string

Uitvoer: 2023-01-01 00:00:00

print(datetime_obj.strftime('%Y-%m-%d %H:%M:%S'))
Deze eenvoudige aanpak geeft je een schone en betrouwbare manier om epoch-tijd in je Python-apps te beheren. En als je werkt met complexe datastructuren zoals JSON die timestamps bevatten, vind je onze gids over het gebruik van een JSON-opmaaktool misschien nuttig voor debugging.

Database-conversies met SQL

Databases slaan tijd vaak op als Unix-timestamps omdat ze efficiënt zijn. Het goede nieuws is dat de meeste SQL-dialecten ingebouwde functies hebben om deze conversies direct in je queries af te handelen.

Dit is veel efficiënter dan het ophalen van ruwe integer-timestamps en deze om te zetten in je applicatiecode.

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

Voor ontwikkelaars is het een enorme productiviteitswinst om SQL te formatteren, timestamps om te zetten en epoch-verschillen te berekenen zonder ooit je machine te verlaten. Deze lokale aanpak houdt je ook compliant met moderne gegevensprivacy-standaarden zoals GDPR en CCPA.

MySQL Voorbeeld

In MySQL is de FROM_UNIXTIME() functie wat je het meest zult gebruiken. Het neemt een epoch-integer en zet deze netjes om in een standaard DATETIME formaat.

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

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

PostgreSQL Voorbeeld

PostgreSQL gebruikt een iets andere, maar even krachtige functie: to_timestamp(). Deze functie zet een Unix-timestamp direct om in een TIMESTAMP WITH TIME ZONE waarde.

SELECT to_timestamp(1672531200);
-- Retourneert: 2023-01-01 00:00:00+00
Omdat het direct tijdzone-bewust is, is het een zeer robuuste keuze voor applicaties die een wereldwijd publiek bedienen waar tijdprecisie niet onderhandelbaar is.

Beheersing van Timestamp-conversies in de Terminal

Als je in de commandoregel werkt, is het overschakelen naar een browser of GUI voor een snelle timestamp-conversie een echte workflow-killer. Het verstoort gewoon je concentratie. Het goede nieuws is dat je dat niet hoeft te doen; zowel Linux als macOS hebben krachtige, native tools om deze conversies uit te voeren zonder ooit de terminal te verlaten.

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

Timestamp-conversies op Linux

Op Linux is de syntaxis schoon en gemakkelijk te onthouden. Je gebruikt gewoon de -d vlag om de datum op te geven, maar je moet het vertellen dat je een epoch-timestamp opgeeft door deze vooraf te laten gaan door een @ symbool.

Laten we zeggen dat je door logs aan het graven bent en de timestamp 1704067200 tegenkomt. Om te zien wat dat eigenlijk betekent, voer je dit uit:

date -d @1704067200

Direct krijg je een leesbare datum terug, iets als Mon Jan 1 00:00:00 UTC 2024. Je kunt die output ook opruimen met je eigen aangepaste formaat.

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

Output: 2024-01-01 00:00:00

Pro Tip: Dit commando wordt een echte krachtpatser wanneer je andere commando's erdoorheen pipet. Je kunt grep een timestamp uit een enorme logbestand halen en deze direct aan date doorgeven voor een instant conversie. Het maakt een meerstaps debuggingtaak tot een enkele, elegante one-liner.

Omgaan met conversies op macOS

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

Hier is hoe je dezelfde timestamp op een Mac zou omzetten:

date -r 1704067200

Net als de Linux-versie kun je opmaakopties toevoegen om de exacte output te krijgen die je wilt.

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

Output: 2024-01-01 00:00:00 UTC

Dit kleine verschil is een klassieke struikelblok voor iedereen die vaak tussen Linux en macOS wisselt. Beide versies onthouden zal je een hoop hoofdpijn besparen in de toekomst.

Als je deze commando's onder de knie hebt, kun je timestamp-conversies direct in je shell-scripts en loganalyse verweven. Het is een kleine vaardigheid, maar het leidt tot aanzienlijke productiviteitswinst, waardoor je in de zone blijft en gefocust op het werk dat ertoe doet.

Veelvoorkomende Timestamp-valkuilen en hoe ze te vermijden

Werken met Unix-timestamps lijkt op het eerste gezicht eenvoudig, maar een paar klassieke fouten kunnen leiden tot echt frustrerende bugs. Deze problemen hebben de vervelende gewoonte om ver weg van de plek waar de fout daadwerkelijk is opgetreden op te duiken, waardoor ze een echte hoofdpijn zijn om te debuggen. Beschouw deze sectie als je veldgids om de meest voorkomende timestamp-traps die ik in de loop der jaren heb gezien, te spotten en te omzeilen.

De Verwarring Tussen Seconden en Milliseconden

Verreweg de meest voorkomende fout is het verwarren van seconden met milliseconden. Een standaard Unix-timestamp 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-cijferige timestamp voor milliseconden. Wanneer een front-end app een milliseconde waarde doorgeeft aan een backend die seconden verwacht, gaat alles mis.

Voor een unix timestamp converter lijkt dat 13-cijferige nummer op een datum duizenden jaren in de toekomst. Dit kan stilletjes de gegevensvalidatie, planningslogica en historische records die je probeert bij te houden, verstoren. Het is het soort subtiele gegevenscorruptie dat je misschien wekenlang niet eens opmerkt.

De Tijdzone-val

Een andere valkuil die zelfs ervaren ontwikkelaars vangt, is het omgaan met tijdzones. Bij zijn definitie is een Unix-timestamp altijd in de gecoördineerde universele tijd (UTC). Het vertegenwoordigt een enkel, universeel moment in de tijd, volledig onafhankelijk van locatie. De valstrik springt wanneer je dit vergeet en aanneemt dat een timestamp de lokale tijd van een gebruiker weerspiegelt.

Deze fout gebeurt meestal wanneer je een timestamp omzet naar een leesbare datum zonder een tijdzone op te geven. Je systeem valt vaak terug op de lokale tijd van de server, wat leidt tot chaos. Een gebruiker in New York kan een tijd zien die bedoeld is voor iemand in Londen, maar het is enkele uren verkeerd.

De gouden regel is simpel: behandel timestamps altijd als UTC in je backend. 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.

Problemen met Veelvoorkomende Timestamp-conversiefouten Oplossen

Wanneer dingen misgaan, kunnen de symptomen verwarrend zijn. Hier is een snelle referentietabel die ik uit ervaring heb samengesteld 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 andere verre toekomst.	Milliseconden vs. Seconden. Je geeft een 13-cijferige milliseconde timestamp door aan een functie die een 10-cijferige seconde timestamp verwacht.	De timestamp delen door 1000 voordat je deze verwerkt. Valideer altijd het aantal cijfers van binnenkomende timestamps.
Tijd is enkele uren verkeerd, maar de datum is correct.	Tijdzone Mishandeling. De timestamp is geconverteerd met behulp van de lokale tijd van de server in plaats van de tijd van de gebruiker of UTC.	Zorg ervoor dat alle conversies expliciet de doel tijdzone opgeven. Converteer alleen naar lokale tijd aan de clientzijde.
De datum blijft hangen op 1 januari 1970.	Ongeldige of Null Timestamp. De timestamp waarde is waarschijnlijk 0, null, of undefined.	Voeg een controle toe om ervoor te zorgen dat de timestamp een geldige positieve integer is voordat je probeert te converteren. Bied een fallback-waarde aan.
Krijgt "Ongeldige Datum" of een NaN fout.	Verkeerd Gegevenstype. De timestamp wordt behandeld als een string of een ander niet-numeriek type wanneer een nummer vereist is.	Parse de timestamp expliciet naar een integer (parseInt() in JS, int() in Python) voordat je deze in datumfuncties gebruikt.

Vergeet niet, een snelle controle op de invoer kan je uren debugging later besparen.

Vermijden van Onduidelijkheid met Standaardformaten

Vertrouwen op ruwe integer-timestamps bij het doorgeven van gegevens tussen systemen kan een recept voor verwarring zijn. Daarom is het standaardiseren op een universeel stringformaat zoals ISO 8601 (2022-05-17T12:00:00Z) zo'n geweldige defensieve zet. Het omzetten van Unix-timestamps (bijv. 1652905200) naar een duidelijk, zelfdocumenterend formaat zoals dit helpt om fouten te voorkomen in een geschat 37% van cross-timezone API-aanroepen.

Gezien het feit dat 72% van de Fortune 500 bedrijven Unix-timestamps gebruiken voor loganalyse, waar een enkele slip-up meer dan $10.000 per uur aan downtime kan kosten, is precisie alles. Je kunt meer lezen over hoe epoch-tijd in verschillende industrieën wordt gebruikt op EpochConverter.

Voor degenen die databases beheren, is consistente timestamp-afhandeling net zo cruciaal. Als je jezelf vaak in de problemen ziet met verschillende timestamp-formaten in je database, kan onze gids over het gebruik van een krachtige SQL formatter je helpen om je queries schoon en voorspelbaar te houden.

Deze beslissingsboom helpt je de juiste opdracht voor je besturingssysteem te kiezen, waardoor syntaxisfouten worden voorkomen wanneer je een snelle conversie nodig hebt.

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

Om je code te beschermen, implementeer altijd controles om de lengte van een binnenkomende timestamp 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 vergiftigen.

Veelgestelde Vragen Over Unix Timestamps

Als je eenmaal de smaak te pakken hebt van Unix-timestamps, komen er vrijwel altijd een paar praktische vragen naar voren. Ik heb gezien dat deze ontwikkelaars op alle niveaus in de problemen brengen, dus laten we de lucht klaren over de meest voorkomende vragen die je in je dagelijkse werk zult tegenkomen.

Waarom Gebruiken Zo Veel API's Timestamps In Plaats Van ISO 8601 Strings?

Het komt echt neer op ruwe efficiëntie. Een Unix-timestamp is gewoon een enkel nummer, waardoor het ongelooflijk compact is in vergelijking met een string zoals '2023-10-27T10:00:00Z'. Die kleinere grootte betekent minder gegevens om over het netwerk te verzenden, wat bandbreedte bespaart en API-responsen kan versnellen.

Ze zijn ook volledig taalagnostisch.

Er is geen ambiguïteit, geen parser-quirks en geen regionale opmaak waar je je zorgen over hoeft te maken. Voor een machine is het verwerken van getallen altijd sneller dan het parseren van strings, dus elke datumcalculatie—zoals het berekenen van de tijd tussen twee evenementen—is computationeel goedkoper. Voor high-performance 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-timestamp is altijd, altijd in UTC. Het heeft geen concept van een tijdzone erin gebakken. Het is gewoon een ruwe telling van seconden vanaf de epoch.

Tijdzones zijn alleen belangrijk wanneer je die timestamp aan een mens moet tonen.

Mijn advies? Blijf bij UTC voor alles aan de achterkant. Sla het op in je database als een UTC-timestamp, geef het door via je API's in UTC, en doe al je server-side logica in UTC. De enige keer dat je het naar een lokale tijdzone zou moeten converteren, is aan de voorkant, vlak voordat je het aan de gebruiker toont. Deze enkele praktijk zal je besparen van een hele universum aan tijdzone- en zomertijdfouten.

Moet ik me Nog Zorgen Maken over het Jaar 2038 Probleem?

Voor de meeste nieuwe projecten waarschijnlijk niet. Het "Jaar 2038 Probleem" is een erfenis van oudere systemen die een 32-bits signed integer gebruikten om de timestamp op te slaan. Zodra dat getal te groot wordt, draait het om en wordt negatief, waardoor datums terug naar 1901 worden gestuurd.

Gelukkig zijn bijna alle moderne systemen—van besturingssystemen tot databases—lang geleden overgestapt op 64-bits integers. Dit duwt het probleem zo ver de weg op (miljarden jaren, in feite) dat het voor ons geen praktische zorg 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 je bewust van te zijn. Weet altijd op welk soort architectuur je bouwt.

Hoe Kan Ik Snel een Timestamp Converteren in Excel of Google Sheets?

Je hoeft je gegevens hiervoor niet naar een aparte Unix-timestampconverter te halen. Een eenvoudige formule doet het trucje. Stel dat je timestamp in cel A1 staat:

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

Voer die formule in, en formatteer de cel als een "Datum" of "Datum Tijd". Het is een redder in nood wanneer je snel gegevensexporten analyseert en je je flow niet wilt onderbreken.

---

Ben je moe van het constant schakelen tussen je editor, de opdrachtregel en een dozijn browsertabs voor simpele taken? De ShiftShift Extensions suite bundelt een krachtige Unix-timestampconverter, JSON formatter, SQL beautifier, en meer direct in je browser. Alles wat je nodig hebt is slechts een sneltoets verwijderd.

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