Unix Timestamp: vad är det, konvertering och lagring i mobil utveckling

Vad är Unix Timestamp?

Unix Timestamp (även känd som POSIX time, Epoch time eller Unix time) — är ett tidsmätningssystem som bestämmer antalet sekunder som har förflutit sedan 1 januari 1970 00:00:00 UTC (Unix-eran). Detta datum valdes som början av räkningen för operativsystemet Unix, och senare blev formatet de facto standard för tidrepresentation i datorsystem. Timestamp tar inte hänsyn till skottsekunder — varje minut räknas som 60 sekunder, även om International Earth Rotation Service ibland lägger till en extra sekund för att korrigera atomtid.

Unix-eran: varför 1970?

Valet av 1 januari 1970 är kopplat till utvecklingshistorien för operativsystemet Unix. Utvecklarna Ken Thompson och Dennis Ritchie valde detta datum som en enkel och rund startpunkt — det var tillräckligt tidigt för att täcka alla möjliga datum och samtidigt tillräckligt sent för att tiden skulle kunna lagras i ett 32-bitars heltal med tecken. Ursprungligen mättes tiden i sextiondelar av en sekund, sedan i tick (1/60 sekund), och först i den sjunde utgåvan av Unix (V7, 1979) stabiliserades formatet som ett helt antal sekunder. Enligt The Open Group Base Specifications (Issue 8, 2024) är POSIX-kompatibla system skyldiga att stödja detta format.

Hur fungerar Unix Timestamp

Arbetsprincipen för Unix Timestamp baseras på en enkel räknare: varje förfluten dag lägger till 86 400 sekunder till värdet. Till exempel motsvarar timestamp 1 720 000 000 ett datum i mitten av 2024 — exakt konvertering kan göras genom att dividera med antalet sekunder på en dag, timme och minut. Ett sådant tillvägagångssätt gör timestamp idealiskt för maskinlagring: det är ett heltal som upptar 4 byte (32-bitars int) eller 8 byte (64-bitars long) och stödjer direkt jämförelse — större timestamp = senare datum.

Matematik för konvertering

En dag = 86 400 sekunder (24 x 60 x 60). En timme = 3600 sekunder. För att konvertera timestamp till datum måste du successivt beräkna antalet dagar, timmar, minuter och sekunder från början av eran. Omvänd konvertering — omvandla datumet till dagar sedan 1970-01-01, multiplicera sedan med 86 400 och lägg till förskjutningen från UTC. I Java och Kotlin är dessa beräkningar redan implementerade i standardklasserna java.time.Instant och java.util.Date, vilket befriar utvecklaren från manuella beräkningar.

        // Få Unix Timestamp i sekunder
val seconds = System.currentTimeMillis() / 1000

// Konvertera timestamp till datum via java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Omvänt: datum till timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Konvertering av Unix Timestamp till datum och tillbaka

Konvertering av Unix Timestamp till ett för människan läsbart datum är en av de vanligaste operationerna inom mobil utveckling. I Android finns flera konverteringsmetoder tillgängliga beroende på lägsta API-version: för API 26+ rekommenderas java.time.Instant, för äldre versioner används java.util.Date och java.text.SimpleDateFormat. Det är viktigt att komma ihåg att Android och JVM som standard använder millisekunder, inte sekunder — om timestamp togs emot från servern i sekunder måste det multipliceras med 1000 innan det skickas till standardkonstruktorer.

Konvertering med användarens tidszon

En av de största fördelarna med Unix Timestamp är oberoendet av plats. Servern returnerar alltid timestamp i UTC, och konvertering till lokalt datum och tid görs på klientsidan. I Kotlin används ZonedDateTime med lämpligt ZoneId för detta — system eller valt av användaren. Om applikationen visar tid i olika zoner (till exempel för resenärer), eliminerar timestamp behovet av att skicka tidszon från servern — en enda tidsstämpel räcker.

// Konvertering med användarens tidszon
fun formatTimestamp(seconds: Long, zoneId: ZoneId): String {
    val instant = Instant.ofEpochSecond(seconds)
    val formatter = DateTimeFormatter
        .ofPattern("dd.MM.yyyy HH:mm:ss")
    return formatter.format(instant.atZone(zoneId))
}

// Exempel: timestamp = 1720000000, zon = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

Problemet med år 2038

Problemet med år 2038 (Year 2038 Problem, Y2K38) — är en grundläggande begränsning av 32-bitars heltal med tecken för lagring av Unix Timestamp. Det maximala värdet för ett 32-bitars signed int är 2 147 483 647, vilket motsvarar 19 januari 2038 kl 03:14:07 UTC. Efter detta datum spiller värdet över och blir ett negativt tal, vilket orsakar fel i system som använder 32-bitars time_t. Problemet liknar den kända Y2K, men påverkar främst inbyggda system, äldre Android-versioner och IoT-enheter med 32-bitars arkitektur.

Problemets omfattning

Enligt Linux Foundation (2025) använder cirka 15% av Linux-enheterna inom industri- och IoT-segmentet fortfarande 32-bitars kompileringar. För Android-enheter är risken lägre — de flesta moderna smartphones kör på 64-bitars processorer (ARM64), men äldre modeller med Android 4.x och lägre kan använda 32-bitars time_t. Lösningen på problemet — migrering till 64-bitars time_t, som är säker i 292 miljarder år. Från och med Android 5.0 (API 21) använder alla enheter 64-bitars tid på kärnnivå. Utvecklare av mobila applikationer behöver bara lagra timestamp i typen Long (64-bitars) för att undvika problemet på applikationsnivå.

Arbete med Unix Timestamp i Android

I Android-utveckling är korrekt arbete med Unix Timestamp avgörande för datasynkronisering, visning av mottagningstid för meddelanden, beräkning av timeout och schemaläggning av notifieringar. Systemanropet System.currentTimeMillis() returnerar aktuell tid i millisekunder sedan Unix-eran — detta är den mest exakta tidkällan som finns tillgänglig på enheten. För nätverksförfrågningar används vanligtvis Unix Timestamp i sekunder, eftersom de flesta REST API:er och databaser arbetar just med sekunder.

Rekommenderade metoder

Använd aldrig System.currentTimeMillis() för att mäta intervall — för detta finns System.nanoTime(), som är monoton och inte påverkas av användarens klockändringar. För tidsvisning, lagra alltid timestamp i UTC och konvertera till lokal tidszon på gränssnittssidan. När du arbetar med databaser (SQLite, Room), använd typen INTEGER och lagra timestamp i sekunder — detta upptar 8 byte (Long) och stödjer inbyggd SQL-sortering. För serialisering i JSON rekommenderas att skicka timestamp som ett tal (Long), inte som en sträng — det är mer kompakt och snabbare att tolka.

// Korrekt mätning av exekveringstid
val start = System.nanoTime()
// ... operation ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Lagra i Room (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp i sekunder
)

Hantering av tid från servern

När du tar emot Unix Timestamp från servern, kontrollera alltid mätenheten: vissa API:er returnerar millisekunder (JavaScript-kompatibla), andra sekunder (POSIX-standard). Överenskommelsen om enheter måste dokumenteras i API-dokumentationen. I server svaret kan timestamp skickas som Long (JSON-nummer) eller String (ISO 8601). För felsökning, lägg till en hjälpfunktion som visar timestamp i ett läsbart format — detta förenklar kontrollen av tidsstämplarnas korrekthet under utvecklingen.

Lagring av tidsstämplar i databaser

Valet av lagringsformat för tid i databasen påverkar direkt prestandan för frågor, kodkomplexitet och korrektheten av arbete med tidszoner. Unix Timestamp — det mest effektiva formatet för relationsdatabaser: det lagras som ett heltal (4 eller 8 byte), stödjer indexering och snabb sortering. Till skillnad från ISO 8601-strängar kräver timestamp ingen tolkning vid sortering och tar mindre plats i indexet. För Room och SQLite rekommenderas att lagra timestamp i typen INTEGER och använda ett index på tidskolumnen.

Rekommendationer för mobilprojekt

För Android-applikationer med Room-biblioteket rekommenderas att lagra timestamp som Long (64-bitars) och använda TypeConverter för automatisk konvertering mellan Long och Date eller Instant. I databasfrågor, använd jämförelseoperatorer (>, <, BETWEEN) — de fungerar inbyggt med numeriska typer. För cachning av data som kräver sortering efter tid (till exempel meddelandelista), skapa obligatoriskt ett index på timestamp-kolumnen — detta kommer att snabba upp frågor med ORDER BY med flera storleksordningar vid stora datamängder.