TimeZone — vad är det, Foundation-klassen och tidszoner

Vad är TimeZone i Foundation?

TimeZone — är en värdetyp i Swift som ger information om en geografisk tidszon: avvikelsen från UTC, namn, förkortning och regler för övergång till sommartid. I Objective-C heter klassen NSTimeZone. Båda klasserna baseras på IANA Time Zone Database (även känd som Olson-databasen), som innehåller historiken över tidszonsändringar sedan 1970.

Varje TimeZone-instans lagrar en tidszonsidentifierare (t.ex. Europe/Moscow), aktuell avvikelse i sekunder från UTC, flaggan isDaylightSavingTime och datumet för nästa övergång. Identifieraren är den primära nyckeln: vid initialisering av TimeZone(identifier:) laddar systemet motsvarande post från enhetens tidszonsdatabas.

Enligt uppgifter från IANA (2024) innehåller databasen över 600 unika tidszonsidentifierare. Apple levererar en del av denna databas i varje version av iOS och macOS, vilket garanterar enhetlighet i beräkningar på alla enheter utan behov av nätverksförfrågningar.

Hur fungerar TimeZone i iOS och macOS?

Arkitektur — TimeZone i Foundation är byggd på ett tvånivåsystem: en tidszonsidentifierare (ett människoläsbart namn) och dess numeriska representation (avvikelse från UTC). Systemet väljer automatiskt aktuell tidszon från enhetens inställningar, men utvecklaren kan åsidosätta den för specifika formateringsoperationer.

TimeZone är nära kopplat till Calendar och DateFormatter. Vid formatering av ett datum använder DateFormatter egenskapen timeZone hos en TimeZone-instans för att konvertera det absoluta tidsögonblicket (Date) till en textrepresentation i rätt tidszon. Om timeZone inte är inställt används standard systemtidszon — TimeZone.current.

Typer av TimeZone-instanser

Viktig nyans: TimeZone(identifier:) returnerar nil för okända identifierare. Detta är en vanlig orsak till app-krascher — utvecklare glömmer att hantera det valfria värdet och skickar en felaktig identifierare från användarinmatning. För IANA-identifierare har versaler betydelse: Europe/Moscow — korrekt, europe/moscow — nil.

Format för tidszonsidentifierare

IANA Time Zone Database använder formatet “Region/Stad” (Continent/City), där regionen är en av kontinenterna (Africa, America, Asia, Atlantic, Australia, Europe, Indian, Pacific) eller ett hav, och staden är den största orten i tidszonsområdet. Detta format garanterar unikhet och läsbarhet för identifieraren.

Förutom huvudformatet stöder TimeZone tre ytterligare identifieringsmetoder: förkortningar (MSK, EST, PST), trebokstavskoder för tidszoner (GMT, UTC) och numeriska avvikelser (+0300, -0500). Förkortningar är dock tvetydiga: EST kan betyda både Eastern Standard Time (GMT-5) och Eastern Summer Time (GMT+10) i Australien. Apple rekommenderar uteslutande användning av IANA-identifierare.

import Foundation

// Hämta alla kända tidszonsidentifierare
let allIdentifiers: [String] = TimeZone.knownTimeZoneIdentifiers
print("Totalt antal tidszoner: \(allIdentifiers.count)")

// Filtrera efter region
let europeZones = allIdentifiers.filter { $0.hasPrefix("Europe/") }
print("Europeiska tidszoner: \(europeZones)")

// Förkortningar (rekommenderas inte för produktion)
if let moscowTimeZone = TimeZone(abbreviation: "MSK") {
    print("MSK-sekunder från GMT: \(moscowTimeZone.secondsFromGMT())")
}

// Hitta identifierare efter avvikelse
let utcPlus3 = TimeZone(secondsFromGMT: 10800)
print("Identifierare: \(utcPlus3.identifier)")

Förkortningar i TimeZone.abbreviationDictionary innehåller förkortningar för alla kända tidszoner, men denna ordbok garanterar inte unikhet: nyckeln PST kan motsvara både America/Los_Angeles och Pacific/Pago_Pago. I produktionskod, använd alltid IANA-identifierare.

Sommartid och TimeZone

TimeZone tar automatiskt hänsyn till övergången till sommar- och vintertid (DST — Daylight Saving Time) för alla regioner där det tillämpas. Systemet använder historiska data från IANA Time Zone Database, som innehåller exakta övergångsdatum för varje tidszon. Egenskapen isDaylightSavingTime returnerar true om tidszonen för närvarande befinner sig i sommartid.

Metoden nextDaylightSavingTimeTransition gör det möjligt att ta reda på datumet för nästa övergång, vilket är användbart för planering av framtida händelser. Denna funktionalitet är särskilt viktig för regioner med frekventa ändringar i DST-regler, som Brasilien eller Marocko — fram till 2024 ändrade Brasilien årligen övergångsdatumen, och manuell beräkning ledde till fel i applikationer.

Enligt uppgifter från Apple WWDC 2023 uppdaterar ICU-biblioteket (International Components for Unicode), som ligger till grund för Foundation, DST-data vid varje iOS-uppdatering. Applikationer bör inte cacha data om sommartid längre än en dag efter en systemuppdatering — IANA-databasen kan ändras även utan uppdatering av OS-versionen genom tidszonsjusteringar.

import Foundation

// Kontrollera DST för Europe/Moscow
let moscow = TimeZone(identifier: "Europe/Moscow")!
let now = Date()
let isMoscowDST = moscow.isDaylightSavingTime(for: now)
print("Moskva för närvarande i DST: \(isMoscowDST)")

// Hämta nästa DST-övergångsdatum
if let nextTransition = moscow.nextDaylightSavingTimeTransition(
    after: now
) {
    let dstOffset = moscow.daylightSavingTimeOffset(
        for: nextTransition
    )
    print("Nästa övergång: \(nextTransition), DST-avvikelse: \(dstOffset)s")
}

// Säker konvertering med DST-medvetenhet
let newYork = TimeZone(identifier: "America/New_York")!
let offsetNY = newYork.secondsFromGMT(for: now)
print("Aktuell NY-avvikelse: \(offsetNY / 3600)h")

Kritisk nyans: secondsFromGMT(for:) tar hänsyn till DST för det angivna datumet, medan secondsFromGMT() endast för aktuell tid. Vid formatering av historiska datum, använd alltid versionen med Date-parametern: secondsFromGMT(for: someHistoricalDate). Skillnaden kan uppgå till 1–2 timmar, vilket är kritiskt för loggar eller historiska data.

TimeZone i Swift: kodexempel

Formatera datum med en specifik tidszon — den vanligaste uppgiften vid arbete med TimeZone. DateFormatter använder egenskapen timeZone för att konvertera Date till text. Om timeZone inte är explicit inställt använder formatteraren TimeZone.current — tidszonen inställd på användarens enhet, vilket kan leda till oväntade resultat för serverdata.

import Foundation

// Formatera datum i specifik tidszon
let formatter = DateFormatter()
formatter.dateFormat = "yyyy-MM-dd HH:mm:ss"

let tokyo = TimeZone(identifier: "Asia/Tokyo")!
formatter.timeZone = tokyo
let tokyoTime = formatter.string(from: Date())
print("Tokio-tid: \(tokyoTime)")

// Tillgängliga identifierare för användarval
let displayNames: [(String, String)] = TimeZone.knownTimeZoneIdentifiers
    .prefix(20)
    .map { ($0, TimeZone(identifier: $0)!.localizedName(
        for: .generic, locale: .current
    )) }

// Jämför två tidszoner
let london = TimeZone(identifier: "Europe/London")!
let difference = tokyo.secondsFromGMT(for: Date())
    - london.secondsFromGMT(for: Date())
print("Tokio-London skillnad: \(difference / 3600)h")

// Arbeta med förkortningsordbok
let knownAbbrevs = TimeZone.abbreviationDictionary
for (abbr, ident) in knownAbbrevs.sorted(by: { $0.key < $1.key }).prefix(5) {
    print("\(abbr) -> \(ident)")
}

Lokaliserat namn på tidszonen via localizedName(for:locale:) returnerar ett människoläsbart namn på angivet språk. Till exempel, för Europe/Moscow med rysk locale returnerar metoden „Moskva” och med engelsk locale — „Moscow Time”. Tillgängliga stilar: .standard (standardnamn), .daylightSaving (sommartid) och .shortGeneric (kort).

import Foundation

let paris = TimeZone(identifier: "Europe/Paris")!
let nameRU = paris.localizedName(
    for: .standard,
    locale: Locale(identifier: "ru_RU")
)
print("Ryskt namn: \(nameRU)")

// Kontrollera om region är i samma dag
let isSameDay = Calendar.current.isDate(
    Date(),
    equalTo: Date(),
    toGranularity: .day
)
print("Samma dag i olika tidszoner: \(isSameDay)")

Serialisering av tidszonsidentifieraren — bästa praxis för att lagra TimeZone i databaser eller UserDefaults. Spara identifieraren (en sträng av typen Europe/Moscow), inte avvikelsen i sekunder eller förkortningen. Avvikelsen kan ändras vid DST-ändring och förkortningen är tvetydig. Återställning: TimeZone(identifier: savedString).

Vanliga misstag vid arbete med TimeZone

Användning av fast avvikelse istället för tidszonsidentifierare — det vanligaste misstaget. TimeZone(secondsFromGMT: 10800) tar inte hänsyn till DST, därför ger denna konstruktion för Europe/Moscow på sommaren en felaktig avvikelse på 1 timme. Använd alltid IANA-identifieraren för regioner med sommartid.

Glömd nil-hantering vid initialisering av TimeZone(identifier:) — det näst vanligaste misstaget. Om användaren anger en identifierare med fel (t.ex. „moscow” istället för „Europe/Moscow”) returnerar konstruktorn nil. Utan hantering av det valfria värdet kraschar appen med ett runtime-fel. Använd guard let eller TimeZone(identifier:) med en känd fallback.

Ignorering av DST vid arbete med framtida datum. TimeZone.secondsFromGMT(for:) — det enda korrekta sättet att få avvikelsen för ett specifikt datum. Användning av secondsFromGMT() utan parameter för historiska eller framtida datum ger avvikelsen för det aktuella ögonblicket, vilket kanske inte motsvarar den faktiska avvikelsen på det angivna datumet, särskilt för regioner med avskaffande eller införande av DST.

Enligt uppgifter från Stack Overflow (2024) handlar cirka 15% av frågorna om DateFormatter om felaktig inställning av timeZone. Typiskt scenario: servern skickar datum i UTC, utvecklaren formaterar det utan att ställa in formatterarens timeZone, och datumet visas i enhetens tidszon, vilket skapar förvirring för användare från olika regioner. Regel: ställ alltid explicit in formatterarens timeZone för serverdata.