En Unix-tidsstempelkonverter er et av de enkle, men uunnværlige verktøyene du vil finne deg selv å bruke hele tiden som utvikler eller dataanalytiker. Det er et praktisk verktøy som oversetter et langt, tilsynelatende tilfeldig tall til en dato og tid vi faktisk kan forstå. Denne oversettelsen er avgjørende når du graver gjennom systemlogger, arbeider med API-er eller forespør databaser hvor tid lagres i dette supereffektive formatet.

Hva er et Unix-tidsstempel og hvorfor er det viktig

Før du virkelig kan sette pris på en god konverter, må du forstå hva det tallet faktisk er. I sin kjerne er et Unix-tidsstempel bare et løpende antall sekunder. Det sporer det totale antallet sekunder som har gått siden 00:00:00 UTC den 1. januar 1970. Det spesifikke øyeblikket i tid er berømt kjent som "Unix-epoken."

Så hvorfor denne metoden? Enkelhet og effektivitet. Å lagre tid som et enkelt heltall er mye mer kompakt og ytelseseffektivt enn en lang tekststreng som "Fredag, 1. januar 2021 12:00:00 AM GMT". Dette gjør det perfekt for noen nøkkelområder:

• Databaselagring: Tidsstempler er små, noe som gjør dem raske å indeksere og forespørre. Det er en stor seier for ytelsen.
• API-payloads: Å sende et enkelt tall frem og tilbake er mye lettere for båndbredden enn å sende en full datostring, noe som fører til raskere responstider.
• Loggfiler: Når du analyserer logger fra dusinvis av forskjellige systemer, er det en livredder å ha et ensartet, språkagnostisk tidsstempel.
• Beregninger: Trenger du å vite hvor lenge en prosess tok? Bare trekk starttidsstempelet fra sluttidspunktet. Det er enkel heltalls-matematikk.

Sekunder vs. Millisekunder og mer

Det klassiske Unix-tidsstempelet er et 10-sifret tall som representerer sekunder. Men etter hvert som teknologien utviklet seg, vokste behovet for mer granulær tidsmåling. Dette er hvor du begynner å se forskjellige lengder av tidsstempler, og det er en vanlig fallgruve.

Her er en rask oversikt over hva du typisk vil støte på der ute. Å forveksle en med en annen er en klassisk "feil med tusen" som kan føre til noen veldig forvirrende feil.

Vanlige Unix-tidsstempelformater ved første øyekast

Enhet	Sifre	Typisk bruksområde	Eksempelverdi (for det samme øyeblikket)
Sekunder	10	Standard for de fleste backend-systemer, databaser og API-er.	1609459200
Millisekunder	13	Veldig vanlig i webteknologi, spesielt JavaScript.	1609459200000
Mikrosekunder	16	Brukes i høyfrekvent handel eller vitenskapelig databehandling.	1609459200000000

Å få disse formatene på plass er nøkkelen. Hvis et verktøy forventer sekunder og du gir det millisekunder, vil du få en dato som er tusenvis av år inn i fremtiden. Det er en feil vi alle har gjort på et eller annet tidspunkt!

Det berømte år 2038-problemet

Den elegante enkelheten til Unix-tidsstempelet skapte også en ticking time bomb: "År 2038-problemet." På eldre 32-bit systemer ble tidsstempler lagret som et signert 32-bit heltall. Problemet er at denne typen heltall har et tak - det kan ikke holde et tall større enn 2,147,483,647.

Den 19. januar 2038, kl. 03:14:07 UTC, vil antallet sekunder siden epoken overskride den grensen. Når det skjer, vil heltallet "wrap around" og bli et negativt tall. Dette vil få sårbare systemer til å tolke datoen som om den var tilbake i 1901, noe som kan krasje milliarder av eldre enheter som fortsatt er der ute. Du kan få mer innsikt om Unix-epoken og dens innvirkning fra ekspertene hos StrongDM.

Heldigvis er dette ikke noe de fleste av oss trenger å bekymre oss for i det daglige. Den store majoriteten av moderne systemer har gått over til 64-bit heltall for tidsmåling. Et 64-bit heltall er så stort at det ikke vil overflyte på ytterligere 292 milliarder år, noe som effektivt løser problemet for godt.

Likevel er det en fantastisk del av databehandlingens historie og en kritisk kunnskap hvis du noen gang finner deg selv arbeider med eldre innebygde systemer eller eldre kodebaser. Å forstå disse grunnleggende prinsippene gjør enhver Unix-tidsstempelkonverter til et mye mer kraftig verktøy i hendene dine.

Gjør konverteringer enkle i nettleseren din

Selv om det å bruke en terminalkommando eller en kodesnutt fungerer, er det ikke alltid den raskeste måten å få ting gjort på. Noen ganger trenger du bare et svar akkurat nå, uten å bryte fokuset ditt eller bytte vinduer. Dette er hvor et godt nettleserbasert verktøy virkelig viser sin verdi, spesielt en dedikert Unix-tidsstempelkonverter som lever rett inne i nettleseren din.

Den virkelige magien her handler om å holde seg i flyten. Tenk deg dette: du graver gjennom et API-svar i nettleserens utviklerverktøy og ser et tidsstempel. I stedet for å åpne en ny fane eller starte opp en terminal, trykker du på en rask hurtigtast, limer inn tallet, og får svaret ditt umiddelbart. Det er den typen sømløs arbeidsflyt du får med verktøy som ShiftShift Extensions, som pakker en haug med nyttige verktøy inn i ett kommandopanel.

Få umiddelbare svar med en hurtigtast

Det hele handler om hastighet. Med et verktøy som ShiftShift, åpner et raskt dobbelttrykk på Shift-tasten (eller Cmd+Shift+P på en Mac) et kommandovindu. Begynn bare å skrive "timestamp," og konvertereren dukker opp. Lim inn verdien din, og du har en menneskelig lesbar dato på stedet.

Her er hvordan det ser ut - kommandopanelet er klart og venter på å konvertere et tidsstempel rett over den nåværende siden din.

Den beste delen er hvordan det integreres uten å komme i veien for deg. Konvertereren er bare ett av mange verktøy tilgjengelig i den samme overlegg, så du trenger aldri å forlate det du holder på med.

Denne tilnærmingen er en livredder for utviklere, testere og alle andre som praktisk talt lever i nettleseren sin. I tillegg skjer konverteringen helt på maskinen din. Sensitiv data fra logger eller API-svar forlater aldri datamaskinen din, noe som er en stor seier for personvernet.

Å kunne konvertere et tidsstempel, omformatere en rotete JSON-blobb, og deretter beregne en tidsforskjell - alt fra samme grensesnitt - er en stor tidsbesparelse. Det forvandler en klumpete, flerverktøyprosess til en enkel, smidig handling.

Mer enn bare en en-triks-ponni

Et flott nettleserverktøy er sjelden bare et enkelt verktøy; det er en del av et helt verktøysett. Du vil ofte finne deg selv bruke tidsstempelkonverteren sammen med andre funksjoner.

For eksempel kan du kombinere det med:

• En JSON- eller SQL-formaterer for å rydde opp i noe kode før du trekker ut tidsstempelet.
• En innebygd kalkulator for å gjøre raske beregninger på epokeverdier. (Du kan leke med et lignende verktøy på ShiftShift kalkulator-side for å se hvordan det fungerer).
• Et tekstkomparasjonsverktøy for å oppdage forskjeller mellom to API-svar, tidsstempler og alt.

Å ha alle disse nødvendighetene på ett sted skaper en mye raskere og mer sammenhengende arbeidsflyt. Det handler ikke bare om bekvemmelighet - det handler om å kutte ut alle de små, repetitive avbrytelsene som legger seg opp og dreper produktiviteten din i løpet av en dag.

Praktiske tidsstempelkonverteringer i kode

Hvis du er utvikler, vet du at det å fikle med tidsstempler bare er en del av jobben. Men la oss være ærlige, syntaksen er aldri helt den samme fra ett språk til et annet. Denne seksjonen er din gå-til-jukseark, pakket med kodesnutter du kan ta og bruke med en gang for plattformene du faktisk jobber på. Ikke mer graving gjennom gamle Stack Overflow-tråder - bare praktiske eksempler for å få deg i gang.

Enten du håndterer data på en webfrontend, skriver et Python-skript eller forespør en database, er konvertering av epoketid en grunnleggende ferdighet. Vi vil gå gjennom de vanligste scenariene, fra å gjøre et epokeheltall til en lesbar streng og deretter gjøre det hele i revers.

Konvertering av tidsstempler i JavaScript

JavaScripts Date-objekt er ditt primære verktøy her, men det har en stor quirks som forvirrer utviklere hele tiden: det opererer i millisekunder, ikke sekunder. Dette er en klassisk kilde til feil når frontend-en din snakker med en backend som bruker standard 10-sifrede, sekundbaserte tidsstempler.

For å korrekt konvertere et standard Unix-tidsstempel (i sekunder) til et Date-objekt, må du multiplisere det med 1000.

// Et standard 10-sifret Unix-tidsstempel (i sekunder)
const unixTimestamp = 1672531200;

// Konverter til millisekunder, opprett deretter et Date-objekt
const dateObject = new Date(unixTimestamp * 1000);

// Formater til en lesbar UTC-streng
// Utdata: Søn, 01 Jan 2023 00:00:00 GMT
console.log(dateObject.toUTCString());

Trenger du det nåværende tidsstempelet? Date.now() gir det til deg i millisekunder. Bare husk å dele på 1000 og runde ned før du sender et standard 10-sifret tidsstempel tilbake til et API.

Håndtering av konverteringer med Python

På backend er Pythons datetime-modul en kraftkilde. Den er utrolig fleksibel og har fantastisk støtte for tidssonebevisste konverteringer, noe som gjør den til et pålitelig valg for tjenester som trenger å håndtere tid med presisjon på tvers av forskjellige regioner.

Her er den enkle måten å konvertere et tidsstempel med datetime-biblioteket:

import datetime

Et standard 10-sifret Unix-tidsstempel

unix_timestamp = 1672531200

Konverter tidsstempelet til et datetime-objekt

datetime_obj = datetime.datetime.fromtimestamp(unix_timestamp)

Formater det til en ren, menneskelig lesbar streng

Utdata: 2023-01-01 00:00:00

print(datetime_obj.strftime('%Y-%m-%d %H:%M:%S'))
Denne enkle tilnærmingen gir deg en ren og pålitelig måte å håndtere epoketid i Python-appene dine. Og hvis du jobber med komplekse datastrukturer som JSON som inneholder tidsstempler, kan du finne vår guide om å bruke en JSON-formaterer nyttig for feilsøking.

Databaskonverteringer med SQL

Databaser lagrer ofte tid som Unix-tidsstempler fordi de er effektive. Den gode nyheten er at de fleste SQL-dialekter har innebygde funksjoner for å håndtere disse konverteringene rett inne i forespørslene dine.

Dette er mye mer effektivt enn å hente rå heltallstidsstempler og konvertere dem i applikasjonskoden din.

Unix-tidsstempelet er nesten universelt, brukt i over 90% av programmeringsspråk—fra JavaScripts Date.now() til Pythons time.time()—som driver billioner av daglige operasjoner. Å få tidssoner riktig er kritisk; en solid unix timestamp convertor kan håndtere over 400 IANA-soner, noe som bidrar til å forhindre feil i anslagsvis 62% av globale applikasjoner som ikke håndterer tidssoner eksplisitt. Du kan finne flere detaljer om den globale adopsjonen av disse verktøyene på Fossa.

For utviklere er det en stor produktivitetsgevinst å kunne formatere SQL, konvertere tidsstempler og beregne epokeforskjeller uten å forlate maskinen din. Denne lokal-første tilnærmingen holder deg også i samsvar med moderne dataprivacystandarder som GDPR og CCPA.

MySQL Eksempel

I MySQL er FROM_UNIXTIME() funksjonen du vil bruke mest. Den tar et epokeheltall og konverterer det pent til et standard DATETIME format.

SELECT FROM_UNIXTIME(1672531200);
-- Returnerer: '2023-01-01 00:00:00'
For å gå den andre veien—fra en datostreng tilbake til et epoke tidsstempel—bruker du bare UNIX_TIMESTAMP().

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

PostgreSQL Eksempel

PostgreSQL bruker en litt annen, men like kraftig funksjon: to_timestamp(). Denne funksjonen konverterer direkte et Unix-tidsstempel til en TIMESTAMP WITH TIME ZONE verdi.

SELECT to_timestamp(1672531200);
-- Returnerer: 2023-01-01 00:00:00+00
Fordi den er tidssonebevisst rett ut av boksen, er det et veldig robust valg for applikasjoner som betjener et globalt publikum der tidsnøyaktighet er ikke-forhandlingsbar.

Mestring av Tidsstempelkonverteringer i Terminalen

Hvis du lever i kommandolinjen, er det en virkelig arbeidsflytdreper å bytte til en nettleser eller GUI for en rask tidsstempelkonvertering. Det bryter bare konsentrasjonen din. Den gode nyheten er at du ikke trenger å; både Linux og macOS har kraftige, innebygde verktøy for å håndtere disse konverteringene uten å forlate terminalen.

Det foretrukne verktøyet for dette er den ydmyke date-kommandoen. Den finnes på praktisk talt hvert Unix-lignende system der ute, men det er en hake: syntaksen for å bruke den som en unix timestamp convertor er forskjellig mellom Linux (GNU) og macOS (BSD). Å vite forskjellen er nøkkelen til å få det riktig hver gang.

Konvertering av Tidsstempler på Linux

På Linux er syntaksen ren og lett å huske. Du bruker bare -d-flagget for å spesifisere datoen, men du må fortelle den at du gir et epoke tidsstempel ved å prefikse det med et @-symbol.

La oss si at du graver gjennom logger og ser tidsstempelet 1704067200. For å se hva det faktisk betyr, kjører du dette:

date -d @1704067200

Umiddelbart får du en menneskelig lesbar dato tilbake, noe som Mon Jan 1 00:00:00 UTC 2024. Du kan også rydde opp den utdataen med ditt eget tilpassede format.

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

Utdata: 2024-01-01 00:00:00

Pro Tips: Denne kommandoen blir en virkelig kraftpakke når du begynner å pipe andre kommandoer inn i den. Du kan grep et tidsstempel fra en massiv loggfil og mate det direkte til date for en øyeblikkelig konvertering. Det forvandler en flertrinns feilsøkingsoppgave til en enkel, elegant en-liner.

Håndtering av Konverteringer på macOS

Nå, hvis du kjører den samme Linux-kommandoen på en Mac, vil den kaste en feil. BSD-versjonen av date som macOS bruker, krever -r-flagget i stedet, og den trenger ikke @-prefikset.

Her er hvordan du ville konvertere det samme tidsstempelet på en Mac:

date -r 1704067200

Akkurat som Linux-versjonen kan du legge til formateringsalternativer for å få nøyaktig den utdataen du ønsker.

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

Utdata: 2024-01-01 00:00:00 UTC

Den lille forskjellen er en klassisk snublestein for alle som ofte hopper mellom Linux og macOS. Å memorere begge versjoner vil spare deg for mange hodepiner senere.

Når du har disse kommandoene under kontroll, kan du veve tidsstempelkonverteringer direkte inn i skriptene dine og logganalyse. Det er en liten ferdighet, men den gir betydelige produktivitetsgevinster, og holder deg i sonen og fokusert på arbeidet som betyr noe.

Vanlige Tidsstempelfeller og Hvordan Unngå Dem

Å jobbe med Unix-tidsstempler virker enkelt på overflaten, men noen klassiske feil kan føre til virkelig frustrerende feil. Disse problemene har en ekkel vane med å dukke opp langt fra der feilen faktisk skjedde, noe som gjør dem til en reell hodepine å feilsøke. Tenk på denne seksjonen som din feltguide til å oppdage og unngå de vanligste tidsstempelfellene jeg har sett gjennom årene.

Forvekslingen mellom Sekunder og Millisekunder

Så langt er den mest hyppige feilen å forveksle sekunder med millisekunder. Et standard Unix-tidsstempel er et 10-sifret heltall som representerer antall sekunder siden epoken. Men mange systemer, spesielt i JavaScript-verdenen, jobber med et 13-sifret tidsstempel for millisekunder. Når en frontend-app sender en millisekundverdi til en backend som forventer sekunder, går ting galt.

For en unix timestamp convertor ser det 13-sifrede tallet ut som en dato tusenvis av år inn i fremtiden. Dette kan stille ødelegge datavalidering, planleggingslogikk og eventuelle historiske poster du prøver å opprettholde. Det er den typen subtile datakorupsjon du kanskje ikke engang legger merke til på uker.

Tidsonefellen

En annen felle som fanger selv erfarne utviklere, er håndtering av tidssoner. I sin essens er et Unix-tidsstempel alltid i Coordinated Universal Time (UTC). Det representerer et enkelt, universelt øyeblikk i tid, helt uavhengig av sted. Fellen utløses når du glemmer dette og antar at et tidsstempel reflekterer en brukers lokale tid.

Denne feilen skjer vanligvis når du konverterer et tidsstempel til en lesbar dato uten å spesifisere en tidssone. Systemet ditt faller ofte tilbake til serverens lokale tid, noe som fører til kaos. En bruker i New York kan se en tid som er ment for noen i London, men den er feil med flere timer.

Den gyldne regelen er enkel: behandle alltid tidsstempler som UTC i backend. Lagre dem som UTC, prosesser dem som UTC, og konverter kun til en brukers lokale tid på frontend, akkurat i det øyeblikket de skal vises.

Feilsøking av Vanlige Tidsstempelkonverteringsfeil

Når ting går galt, kan symptomene være forvirrende. Her er en rask referansetabell jeg har satt sammen fra erfaring for å hjelpe deg med å diagnostisere og fikse de vanligste problemene på farten.

Symptom	Sannsynlig Årsak	Løsning
Datoen er i året 52361 eller et annet fjernt fremtid.	Millisekunder vs. Sekunder. Du sender et 13-sifret millisekundtidsstempel til en funksjon som forventer et 10-sifret sekundtidsstempel.	Del tidsstempelet med 1000 før prosessering. Valider alltid antall sifre i innkommende tidsstempler.
Tiden er feil med noen timer, men datoen er korrekt.	Tidsonehåndtering. Tidsstempelet ble konvertert ved å bruke serverens lokale tid i stedet for brukerens eller UTC.	Sørg for at alle konverteringer eksplisitt spesifiserer mål-tidssonen. Konverter til lokal tid kun på klientsiden.
Datoen sitter fast på 1. januar 1970.	Ugyldig eller Null Tidsstempel. Tidsstempelverdien er sannsynligvis 0, null, eller undefined.	Legg til en sjekk for å sikre at tidsstempelet er et gyldig positivt heltall før du prøver å konvertere. Gi en fallback-verdi.
Får "Ugyldig Dato" eller en NaN-feil.	Feil Datatype. Tidsstempelet behandles som en streng eller en annen ikke-numerisk type når et tall kreves.	Parsel tidsstempelet eksplisitt til et heltall (parseInt() i JS, int() i Python) før du bruker det i datofunksjoner.

Husk, en rask sjekk av inngangen kan spare deg for timer med feilsøking senere.

Unngå Uklarhet med Standardformater

Å stole på rå heltallstidsstempler når du sender data mellom systemer kan være en oppskrift på forvirring. Dette er grunnen til at standardisering på et universelt strengformat som ISO 8601 (2022-05-17T12:00:00Z) er et så godt defensivt trekk. Å konvertere Unix-tidsstempler (f.eks. 1652905200) til et klart, selv-dokumenterende format som dette bidrar til å forhindre feil i anslagsvis 37% av API-kall på tvers av tidssoner.

Med tanke på at 72% av Fortune 500-selskaper bruker Unix-tidsstempler for logganalyse, der en enkelt feil kan koste over $10,000 per time i nedetid, er presisjon alt. Du kan lese mer om hvordan epoketid brukes i forskjellige industrier på EpochConverter.

For de som administrerer databaser, er konsekvent håndtering av tidsstempler like kritisk. Hvis du ofte finner deg selv i å kjempe med forskjellige tidsstempelformater i databasen din, kan vår guide til å bruke en kraftig SQL formatter hjelpe deg med å holde forespørslene dine rene og forutsigbare.

Denne beslutningstreet hjelper deg med å velge riktig kommando for operativsystemet ditt, og forhindrer syntaksfeil når du trenger en rask konvertering.

Flytskjemaet ovenfor viser tydelig den avgjørende syntaksforskjellen mellom date-kommandoen på Linux (-d @...) og macOS (-r ...)—en vanlig snublestein for utviklere som jobber på tvers av forskjellige miljøer.

For å gjøre koden din mer robust, implementer alltid sjekker for å validere lengden på et innkommende tidsstempel. En enkel funksjon som sjekker for et 10-sifret (sekunder) eller 13-sifret (millisekunder) verdi kan fange disse feilene før de noen gang forurenser logikken i applikasjonen din.

Vanlige Spørsmål Om Unix Tidsstempler

Når du først får taket på Unix-tidsstempler, dukker det opp noen praktiske spørsmål nesten alltid. Jeg har sett disse snuble utviklere på alle nivåer, så la oss rydde opp i de vanligste spørsmålene du vil møte i ditt daglige arbeid.

Hvorfor Bruker Så Mange API-er Tidsstempler I Stedet For ISO 8601 Strenger?

Det koker virkelig ned til rå effektivitet. Et Unix-tidsstempel er bare et enkelt tall, noe som gjør det utrolig kompakt sammenlignet med en streng som '2023-10-27T10:00:00Z'. Den mindre størrelsen betyr mindre data å sende over nettet, noe som sparer båndbredde og kan øke hastigheten på API-responser.

De er også helt språkagnostiske. Det er ingen tvetydighet, ingen parsingproblemer, og ingen regionale formateringer å bekymre seg for. For en maskin er det alltid raskere å behandle tall enn å analysere strenger, så alle datoberegninger—som å finne ut tiden mellom to hendelser—er beregningsmessig billigere. For høyytelsessystemer er denne enkelheten en stor fordel.

Hva er den riktige måten å håndtere tidssoner på?

Dette er den store. Her er den gyldne regelen: En Unix-tidsstempel er alltid, alltid i UTC. Den har ikke noe begrep om en tidssone innebygd. Det er bare et rått antall sekunder fra epoken.

Tidssoner er kun viktige når du trenger å vise det tidsstempelet til et menneske.

Mitt råd? Hold deg til UTC for alt på backend. Lagre det i databasen din som et UTC-tidsstempel, send det gjennom API-ene dine i UTC, og gjør all serverlogikk i UTC. Den eneste gangen du bør konvertere det til en lokal tidssone er på frontend, rett før du viser det til brukeren. Denne enkle praksisen vil redde deg fra et helt univers av tidssone- og sommertidfeil.

Bør jeg fortsatt bekymre meg for år 2038-problemet?

For de fleste nye prosjekter, sannsynligvis ikke. "År 2038-problemet" er en rest fra eldre systemer som brukte en 32-bits signert heltall for å lagre tidsstempelet. Når det tallet blir for stort, går det rundt og blir negativt, noe som sender datoene tilbake til 1901.

Takk og lov, nesten alle moderne systemer—fra operativsystemer til databaser—har for lenge siden gått over til 64-bits heltall. Dette sparker boksen så langt nedover veien (milliarder av år, faktisk) at det ikke lenger er en praktisk bekymring for oss.

Når det er sagt, hvis du vedlikeholder et eldre system eller jobber med innebygd maskinvare (tenk IoT-enheter), er det absolutt noe å være klar over. Vær alltid klar over hvilken type arkitektur du bygger på.

Hvordan kan jeg raskt konvertere et tidsstempel i Excel eller Google Sheets?

Du trenger ikke å trekke dataene dine ut i en separat Unix-tidsstempelkonverterer for dette. En enkel formel vil gjøre trikset. Anta at tidsstempelet ditt er i celle A1:

• For tidsstempler i sekunder (10 sifre): =A1 / 86400 + DATE(1970,1,1)
• For tidsstempler i millisekunder (13 sifre): =A1 / 86400000 + DATE(1970,1,1)

Bare legg inn den formelen, og formater deretter cellen som en "Dato" eller "Dato og tid". Det er en livredder når du raskt analyserer dataeksporter og ikke vil bryte flyten din.

---

Lei av å hele tiden bytte mellom redigeringsprogrammet ditt, kommandolinjen og et dusin nettleserfaner for enkle oppgaver? ShiftShift Extensions-pakken samler en kraftig Unix-tidsstempelkonverterer, JSON-formatør, SQL-beautifier, og mer rett inn i nettleseren din. Alt du trenger er bare et hurtigtast unna.

Få ShiftShift Extensions og forenkle arbeidsflyten din i dag på https://shiftshift.app