En utviklers guide til Unix-tidsstempelkonverteren

En Unix-tidsstempelkonverter er et av de enkle, men uunnværlige verktøyene du vil finne deg selv bruke stadig som utvikler eller dataanalytiker. Det er et nyttig 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 i systemlogger, jobber med APIer eller spør databaser der tiden er lagret i dette super-effektive formatet.

Hva er en Unix-tidsstempel og hvorfor er det viktig

Før du virkelig kan sette pris på en god konverter, må du forstå hva dette tallet faktisk er. I kjernen er en Unix-tidsstempel bare en telling av sekunder. Den sporer det totale antall sekunder som har gått siden 00:00:00 UTC 1. januar 1970. Det bestemte øyeblikket i tid er kjent som "Unix-epoken."

Så hvorfor denne metoden? Enkelhet og effektivitet. Å lagre tid som et heltall er mye mer kompakt og ytelsesvennlig enn en lang streng som "fredag 1. januar 2021 kl. 00:00:00 GMT". Dette gjør det perfekt for noen nøkkelområder:

• Database Lagring: Tidsstempler er små, noe som gjør dem raske å indeksere og spørre mot. Det er en stor gevinst for ytelsen.
• API-data: Å sende et enkelt tall frem og tilbake er mye lettere på båndbredden enn å sende en full datostreng, noe som gir raskere responstider.
• Loggfiler: Når du analyserer logger fra dusinvis av ulike systemer, er et enhetlig, språkuavhengig tidsstempel en redningsmann.
• Beregninger: Trenger du å vite hvor lang tid en prosess tok? Trekk bare start-tidsstempla fra slutt-tidsstempla. Det er enkel helsetall-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. Her begynner du å se tidsstempler av forskjellige lengder, og dette er et vanlig hinder.

Her er en rask oversikt over hva du typisk vil møte i det virkelige livet. Å forveksle ett med et annet er en klassisk "av-med-en-tusen"-feil som kan føre til些 svært forvirrende feil.

Vanlige Unix-tidsstempelformater på ett blikk

Enhet	Sifre	Typisk Bruksområde	Eksempelverdi (for samme øyeblikk)
Sekunder	10	Standard for de fleste baksystemer, databaser og APIer.	1609459200
Millisekunder	13	Svært vanlig i nett-teknologi, spesielt JavaScript.	1609459200000
Mikrosekunder	16	Brukt i høyfrekvent handel eller vitenskapelig databehandling.	1609459200000000

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

Det berømte Problemet med Året 2038

Unix-tidsstempelets elegante enkelhet skapte også en tikende tidsbombe: "problemet med året 2038". På eldre 32-bits 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 klokken 03:14:07 UTC vil antall sekunder siden epoken overstige denne grensen. Når dette skjer, vil tallet "rulle over" og bli et negativt tall. Dette ville få sårbare systemer til å tolke datoen som tilbake i 1901, noe som kan krasje milliarder av eldre enheter som fortsatt er i bruk. Du kan få mer innsikt i Unix-epoken og dens påvirkning fra ekspertene hos StrongDM.

Heldigvis er dette ikke noe de fleste av oss trenger å bekymre oss for daglig. Den overveldende majoriteten av moderne systemer har gått over til 64-bit heltall for tidsregnskap. Et 64-bit heltall er så stort at det ikke vil flyte over på enda 292 milliarder år, og løser dermed problemet permanent.

Likevel er dette et fantastisk stykke datahistorie og en kritisk bit av kunnskap hvis du en gang finner deg selv å jobbe med eldre innbygde systemer eller arvede kodesystemer. Å forstå disse grunnleggende prinsippene gjør enhver Unix-tidsstemplomformer til et langt kraftigere verktøy i dine hender.

Gjør konverteringer enkelt i nettleseren din

Selv om å bruke en terminalkommando eller et 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 konsentrasjonen din eller bytte vindu. Her er det et godt nettleserverktøy virkelig viser sin verdi, spesielt en dedikert Unix-tidsstemplomformer som bor rett i nettleseren din.

Den virlige magien her handler om å forbli i flyten. Tenk deg dette: du graver gjennom et API-svar i nettleserens utviklerverktøy og legger merke til et tidsstempel. I stedet for å åpne en ny fane eller starte en terminal, trykker du en rask tastaturgenvei, limer inn tallet, og får svaret umiddelbart. Det er den sømløse arbeidsflyten du får med verktøy som ShiftShift Extensions, som pakker en haug med nyttige verktøy inn i ett Kommandopalett.

Få øyeblikkelige svar med en tastaturgenvei

Det handler alt om hastighet. Med et verktøy som ShiftShift åpner et raskt dobbelttrykk på Shift-tasten (eller Cmd+Shift+P på en Mac) en kommandolinje. Bare begynn å skrive "tidsstempel," og omformeren dukker opp. Lim inn verdien din, og du har et menneskelig lesbart dato øyeblikkelig.

Slik ser det ut — Kommandopalettet er klart og venter på å konvertere et tidsstempel rett over den nåværende siden din.

Det beste er hvordan det integrerer seg uten å komme i veien. Omformeren er bare ett av mange verktøy tilgjengelig i samme overlegg, slik at du aldri trenger å forlate det du holder på med.

Denne tilnærmingen er en redningsplanke for utviklere, testere og alle andre som praktisk talt bor i nettleseren sin. I tillegg skjer konverteringen helt på din maskin. Sensitive data fra logger eller API-svar forlater aldri datamaskinen din, noe som er en enorm fordel for personvernet.

Å kunne konvertere et tidsstempel, reformattere en rotete JSON-blob og deretter beregne en tidsforskjell — alt fra samme grensesnitt — er en enorm tidsbesparelse. Det gjør en klumpete, flerverktøys-prosess til én jevn handling.

Mer enn bare et et-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 tidsstemplomformeren sammen med andre funksjoner.

For eksempel kan du kombinere det med:

• En JSON- eller SQL-formatterer for å rydde opp litt kode før du tar frem tidsstempelet.
• En integrert kalkulator for å gjøre raske beregninger på epokeverdier. (Du kan leke med et lignende verktøy på ShiftShift-kalkulatorsiden for å se hvordan det fungerer).
• Et tekstsammenligningsverktøy for å oppdage forskjeller mellom to API-svar, tidsstempler inkludert.

Å ha alle disse essensielle verktøyene 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 avbrytene som legger seg til og dreper produktiviteten din i løpet av en dag.

Praktiske tidsstempelkonverteringer i kode

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

Enten du håndterer data på et web-grensesnitt, skriver et Python-skript eller utfører spørringer i en database, er konvertering av epoktid en grunnleggende ferdighet. Vi vil gjennomgå de vanligstescenarioene, fra å gjøre om et epoktall til en lesbare streng og deretter gjøre hele prosessen omvendt.

Konvertering av Tidsstemplinger i JavaScript

JavaScripts Date-objekt er ditt viktigste verktøy her, men det har en stor egenhet som ofte forvirrer utviklere: det opererer i millisekunder, ikke sekunder. Dette er en klassisk feilkilde når frontenden din kommuniserer med en backend som bruker standard 10-sifrede, sekundbaserte tidsstemplinger.

For å korrekt konvertere et standard Unix-tidsstempel (i sekunder) til et Date-objekt, må du gange det med 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());

Trenger du nåværende tidsstempel? Date.now() gir det til deg i millisekunder. Husk bare å dele på 1000 og avrunde nedover før du sender et standard 10-sifret tidsstempel tilbake til en API.

Håndtering av Konverteringer med Python

På backenden er Pythons datetime-modul en kraftpakke. 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 håndterer tid med presisjon på tvers av ulike 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

Utskrift: 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 epoktid i Python-appene dine. Og hvis du jobber med komplekse datastrukturer som JSON som inneholder tidsstemplinger, kan du finne vår guide om bruk av en JSON-formaterer nyttig for feilsøking.

Databasekonverteringer med SQL

Databaser lagrer ofte tid som Unix-tidsstemplinger fordi de er effektive. Det gode er at de fleste SQL-dialekter har innebygde funksjoner for å håndtere disse konverteringene rett i spørringene dine. Dette er langt mer effektivt enn å hente rå heltallstidsstemplinger og konvertere dem i applikasjonskoden din.

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

For utviklere er evnen til å formatere SQL, konvertere tidsstemplinger og beregne epoktforskjeller uten å forlate maskinen din en enorm produktivitetsgevinst. Denne lokale-først-tilnærmingen holder deg også i samsvar med moderne dataprivatstandarder som GDPR og CCPA.

MySQL-eksempel

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

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

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

PostgreSQL-eksempel

PostgreSQL bruker en litt annen, men likevel kraftig funksjon: to_timestamp(). Denne funksjonen konverterer direkte en 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 den et veldig robust valg for applikasjoner som betjener et globalt publikum der tidsnøyaktighet er ukrenkelig.

Mestring av tidsstempelkonverteringer i terminalen

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

Det foretrukne verktøyet for dette er det beskjedne date-kommandoen. Det finnes på praktisk talt alle Unix-lignende systemer, men det er et hake: syntaksen for å bruke den som en unix-tidsstempelkonverter er forskjellig mellom Linux (GNU) og macOS (BSD). Å kjenne forskjellen er nøkkelen til å gjøre 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 en epoch-tidsstempel ved å sette et @-symbol foran.

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 tilbake en menneskelig lesbart dato, noe som ligner Mon Jan 1 00:00:00 UTC 2024. Du kan også rydde opp i utdataene med ditt eget format.

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

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

Profftips: Denne kommandoen blir et skikkelig kraftverk når du begynner å pipe andre kommandoen inn i den. Du kan grep et tidsstempel fra en enorm loggfil og mate det direkte til date for øyeblikkelig konvertering. Det forvandler et flertrinns feilsøkingsoppdrag til en enkelt, elegant en-linjer.

Håndtering av konverteringer på macOS

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

Slik konverterer du det samme tidsstempelet på en Mac:

date -r 1704067200

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

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

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

Denne lille forskjellen er et klassisk绊脚石 for alle som ofte hopper mellom Linux og macOS. Å memorere begge versjonene vil spare deg for mye hodepine senere.

Når du har disse kommandoenene inne, kan du flette inn tidsstempelkonverteringer direkte i skallskriptene og logganalysen din. Det er en liten ferdighet, men det legger opp til noen alvorlige produktivitetsgevinster, og holder deg i sonen og fokusert på arbeidet som betyr noe.

Vanlige tidsstempelfeller og hvordan unngå dem

Å jobbe med Unix-tidsstempler virker overfladisk sett enkelt, men noen klassiske feil kan føre til noen virkelig galskapsfremkallende bugs. Disse problemene har en vane med å dukke opp langt unna der feilen faktisk skjedde, noe som gjør dem til et mareritt å feilsøke. Tenk på denne delen som din feltguide for å oppdage og unngå de vanligste tidsstempeltriksene jeg har sett gjennom årene.

Forvekslingen mellom sekunder og millisekunder

Den vanligste feilen er forvekslingen av sekunder og millisekunder. Et standard Unix-tidsstempel er et 10-sifret heltall som representerer antall sekunder siden epoch. 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 skikkelig galt.

For en unix timestamp convertor, så ser det 13-sifrede nummeret ut som en dato tusenvis av år i fremtiden. Dette kan i stillhet ødelegge data-validering, planleggingslogikk og alle historiske poster du prøver å holde på. Det er den typen subtile datakorrigeringer som du kanskje ikke legger merke til på flere uker.

Tidsfelle

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

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

Den gylne regelen er enkel: behandle alltid tidsstempler som UTC i backenden din. Lagre dem som UTC, prosesser dem som UTC, og konverter kun til brukerens lokale tid på front-end, rett i øyeblikket de vises.

Feilsøking av vanlige tidsstempelkonverteringsfeil

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

Symptom	Sannsynlig årsak	Løsning
Datoen er i året 52361 eller en annen fjern fremtid.	Millisekunder vs. Sekunder. Du sender et 13-sifret millisekund-tidsstempel til en funksjon som forventer et 10-sifret sekundtidsstempel.	Divider tidsstempelet med 1000 før behandling. Valider alltid sifferantallet på innkommende tidsstempler.
Tiden er av noen timer, men datoen er korrekt.	Tidsfeilhå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 er fast på 1. januar 1970.	Ugyldig eller Nulltidsstempel. Tidsstempelverdien er sannsynligvis 0, null, eller undefined.	Legg til en sjekk for å sikre at tidsstempelet er et gyldig positivt heltall før du forsøker konvertering. Gi en reserveverdi.
Får "Invalid Date" eller en NaN feil.	Feil datatype. Tidsstempelet blir behandlet som en streng eller en annen ikke-numerisk type når et tall kreves.	Analysér eksplisitt tidsstempelet til et heltall (parseInt() i JS, int() i Python) før du bruker det i datofunksjoner.

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

Unngå tvetydighet med standardformater

Å stole på rå heltallstidsstempler når du overfører 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 tiltak. Å konvertere Unix-tidsstempler (f.eks., 1652905200) til et klart, selvforklarende format som dette bidrar til å forhindre feil i et estimert 37% av kryss-tidssone API-kall.

I betraktning av at 72% av Fortune 500-selskaper bruker Unix-tidsstempler for logganalyse, der et enkelt feilsteg kan koste over $10,000 per time i driftstid, er presisjon alt. Du kan lese mer om hvordan epoketid brukes i ulike bransjer på EpochConverter.

For de som administrerer databaser, er konsistent tidsstempelhåndtering like viktig. Hvis du ofte sliter med ulike tidsstempelformater i databasen din, kan vår guide om bruk av en kraftig SQL-formaterer hjelpe deg med å holde spørringene dine rene og forutsigbare.

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

Flytdiagrammet ovenfor viser tydelig den avgjørende syntaktiske forskjellen mellom date kommandoen på Linux (-d @...) og macOS (-r ...) – en vanlig felle for utviklere som jobber på tvers av ulike miljøer.

For å gjøre koden din robust, bør du alltid implementere sjekker som validerer lengden på en innkommende tidsstempel. En enkel funksjon som kontrollerer om verdien er 10-sifret (sekunder) eller 13-sifret (millisekunder) kan fange disse feilene før de i det hele tatt rekker å forringe logikken i applikasjonen din.

Vanlige spørsmål om Unix-tidsstempler

Når du først har forstått Unix-tidsstempler, dukker det nesten alltid opp noen praktiske spørsmål. Jeg har sett disse skape trøbbel for utviklere på alle nivåer, så la oss klargjøre de vanligste du vil møte i det daglige arbeidet ditt.

Hvorfor bruker så mange APIer tidsstempler i stedet for ISO 8601-strenger?

Det koker egentlig ned til ren effektivitet. Et Unix-tidsstempel er bare ett 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-svar.

De er også helt språkuavhengige. Det er ingen tvetydighet, ingen merkelige fortolkningsregler og ingen regional formatering å bekymre seg over. For en maskin er det alltid raskere å bearbeide tall enn å analysere strenger, så alle datoregnskap – som å finne tiden mellom to hendelser – er beregningsmessig billigere. For høytytende systemer er denne enkelheten en stor fordel.

Hva er riktig måte å håndtere tidssoner på?

Dette er det store spørsmålet. Her er den gyldne regelen: Et Unix-tidsstempel er alltid, alltid i UTC. Det har ikke noe konsept om tidssone innbygget i seg. Det er bare en rå telling av sekunder siden epoken.

Tidssoner betyr bare noe når du trenger å vise det tidsstempelet til et menneske.

Mitt råd? Bruk UTC for alt på backenden. Lagre det i databasen som et UTC-tidsstempel, send det gjennom APIene dine i UTC, og gjennomfør all logikk på serversiden i UTC. Det eneste tidspunktet du bør konvertere det til en lokal tidssone er på frontend, rett før du viser det for brukeren. Denne ene praksisen vil spare deg for en hel verden av feil relatert til tidssoner og sommertid.

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

For de fleste nye prosjekter, trolig ikke. "År 2038-problemet" er et etterslep fra eldre systemer som brukte en 32-bit heltall med fortegn for å lagre tidsstempelet. Når det tallet blir for stort, snur det rundt og blir negativt, og sender datoen tilbake til 1901.

Heldigvis har nesten alle moderne systemer – fra operativsystemer til databaser – for lenge siden gått over til 64-bit heltall. Dette skyver egentlig problemet så langt fram i tid (milliarder av år, faktisk) at det lenger ikke er en praktisk bekymring for oss.

Det sagt, hvis du vedlikeholder et eldre system eller jobber med innebygd maskinvare (tenk IoT-enheter), er det definitivt noe å være klar over. Sørg alltid for å kjenne til hvilken arkitektur du bygger på.

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

Du trenger ikke å flytte dataene dine ut til en egen Unix-tidsstempelkonverter for dette. En enkel formel gjør jobben. Anta at tidsstempel 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 sett inn den formelen, og formater deretter cellen som en "Dato" eller "Dato og klokkeslett". Det er en redningsmann når du raskt skal analysere dataeksporter og ikke vil bryte flyten.

---

Lei av å stadig vekk bytte mellom redigeringsprogrammet, kommandolinjen og et dusin faner i nettleseren for enkle oppgaver? ShiftShift Extensions-pakken gir deg en kraftig Unix-tidsstempelkonverter, JSON-formateringsverktøy, SQL-formateringsverktøy og mer, rett i nettleseren din. Alt du trenger er bare en tastatursnarvei unna.

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