TimeZone — wat is het, Foundation-klasse en tijdzones

Wat is TimeZone in Foundation?

TimeZone — is een waardetype in Swift dat informatie geeft over een geografische tijdzone: de afwijking ten opzichte van UTC, naam, afkorting en regels voor zomertijd. In Objective-C heet de klasse NSTimeZone. Beide klassen zijn gebaseerd op de IANA Time Zone Database (ook bekend als de Olson-database), die de geschiedenis van tijdzone-wijzigingen sinds 1970 bevat.

Elke TimeZone-instantie slaat een tijdzone-identifier (bijv. Europe/Moscow), de huidige afwijking in seconden van UTC, de isDaylightSavingTime-vlag en de datum van de volgende overgang op. De identifier is de primaire sleutel: bij initialisatie van TimeZone(identifier:) laadt het systeem het bijbehorende record uit de tijdzone-database van het apparaat.

Volgens gegevens van IANA (2024) bevat de database meer dan 600 unieke tijdzone-identifiers. Apple levert een deel van deze database mee in elke versie van iOS en macOS, wat uniformiteit van berekeningen op alle apparaten garandeert zonder dat er netwerkverzoeken nodig zijn.

Hoe werkt TimeZone in iOS en macOS?

Architectuur — TimeZone in Foundation is gebouwd op een tweeledig systeem: een tijdzone-identifier (een voor mensen leesbare naam) en de numerieke weergave ervan (afwijking van UTC). Het systeem selecteert automatisch de huidige tijdzone uit de apparaatinstellingen, maar de ontwikkelaar kan deze overschrijven voor specifieke formattingsbewerkingen.

TimeZone is nauw verbonden met Calendar en DateFormatter. Bij het formatteren van een datum gebruikt DateFormatter de timeZone-eigenschap van een TimeZone-instantie om het absolute tijdstip (Date) om te zetten naar een tekstweergave in de juiste tijdzone. Als timeZone niet is ingesteld, wordt de standaard systeemtijdzone gebruikt — TimeZone.current.

Typen TimeZone-instanties

Belangrijke nuance: TimeZone(identifier:) retourneert nil voor onbekende identifiers. Dit is een veelvoorkomende oorzaak van app-crashes — ontwikkelaars vergeten de optionele waarde af te handelen en geven een onjuiste identifier door vanuit gebruikersinvoer. Voor IANA-identifiers is hoofdlettergevoeligheid van belang: Europe/Moscow — correct, europe/moscow — nil.

Indelingen van tijdzone-identifiers

IANA Time Zone Database gebruikt de indeling „Regio/Stad” (Continent/City), waarbij de regio een van de continenten (Africa, America, Asia, Atlantic, Australia, Europe, Indian, Pacific) of een oceaan is, en de stad de grootste nederzetting in het tijdzonegebied. Deze indeling garandeert uniciteit en leesbaarheid van de identifier.

Naast de primaire indeling ondersteunt TimeZone drie aanvullende identificatiemethoden: afkortingen (MSK, EST, PST), drieletterige tijdzonecodes (GMT, UTC) en numerieke afwijkingen (+0300, -0500). Afkortingen zijn echter dubbelzinnig: EST kan zowel Eastern Standard Time (GMT-5) als Eastern Summer Time (GMT+10) in Australië betekenen. Apple raadt aan uitsluitend IANA-identifiers te gebruiken.

import Foundation

// Alle bekende tijdzone-identifiers ophalen
let allIdentifiers: [String] = TimeZone.knownTimeZoneIdentifiers
print("Totaal aantal tijdzones: \(allIdentifiers.count)")

// Filteren op regio
let europeZones = allIdentifiers.filter { $0.hasPrefix("Europe/") }
print("Europese tijdzones: \(europeZones)")

// Afkortingen (niet aanbevolen voor productie)
if let moscowTimeZone = TimeZone(abbreviation: "MSK") {
    print("MSK-seconden vanaf GMT: \(moscowTimeZone.secondsFromGMT())")
}

// Identifier vinden op afwijking
let utcPlus3 = TimeZone(secondsFromGMT: 10800)
print("Identifier: \(utcPlus3.identifier)")

Afkortingen in TimeZone.abbreviationDictionary bevatten afkortingen voor alle bekende tijdzones, maar deze woordenlijst garandeert geen uniciteit: de sleutel PST kan zowel overeenkomen met America/Los_Angeles als met Pacific/Pago_Pago. Gebruik in productiecode altijd IANA-identifiers.

Zomertijd en TimeZone

TimeZone houdt automatisch rekening met de overgang naar zomer- en wintertijd (DST — Daylight Saving Time) voor alle regio’s waar dit gebruikelijk is. Het systeem gebruikt historische gegevens uit de IANA Time Zone Database, die exacte overgangsdatums voor elke tijdzone bevat. De eigenschap isDaylightSavingTime retourneert true als de tijdzone zich momenteel in zomertijd bevindt.

De methode nextDaylightSavingTimeTransition maakt het mogelijk de datum van de volgende overgang te achterhalen, wat nuttig is voor het plannen van toekomstige gebeurtenissen. Deze functionaliteit is vooral belangrijk voor regio’s met frequente wijzigingen in DST-regels, zoals Brazilië of Marokko — tot 2024 veranderde Brazilië jaarlijks de overgangsdatums, en handmatige berekening leidde tot fouten in apps.

Volgens gegevens van Apple WWDC 2023 werkt de ICU-bibliotheek (International Components for Unicode), die aan de basis van Foundation ligt, DST-gegevens bij bij elke iOS-update. Apps mogen gegevens over zomertijd niet langer dan één dag na een systeemupdate in de cache bewaren — de IANA-database kan zelfs zonder update van de OS-versie veranderen via tijdzone-aanpassingen.

import Foundation

// DST controleren voor Europe/Moscow
let moscow = TimeZone(identifier: "Europe/Moscow")!
let now = Date()
let isMoscowDST = moscow.isDaylightSavingTime(for: now)
print("Moskou momenteel in DST: \(isMoscowDST)")

// Volgende DST-overgangsdatum ophalen
if let nextTransition = moscow.nextDaylightSavingTimeTransition(
    after: now
) {
    let dstOffset = moscow.daylightSavingTimeOffset(
        for: nextTransition
    )
    print("Volgende overgang: \(nextTransition), DST-afwijking: \(dstOffset)s")
}

// Veilige conversie met DST-bewustzijn
let newYork = TimeZone(identifier: "America/New_York")!
let offsetNY = newYork.secondsFromGMT(for: now)
print("Huidige NY-afwijking: \(offsetNY / 3600)h")

Kritieke nuance: secondsFromGMT(for:) houdt rekening met DST voor de opgegeven datum, terwijl secondsFromGMT() alleen voor de huidige tijd. Gebruik bij het formatteren van historische datums altijd de versie met de Date-parameter: secondsFromGMT(for: someHistoricalDate). Het verschil kan 1–2 uur bedragen, wat kritiek is voor logs of historische gegevens.

TimeZone in Swift: codevoorbeelden

Datum formatteren met een specifieke tijdzone — de meest voorkomende taak bij het werken met TimeZone. DateFormatter gebruikt de timeZone-eigenschap om Date naar tekst om te zetten. Als timeZone niet expliciet is ingesteld, gebruikt de formatter TimeZone.current — de tijdzone die op het apparaat van de gebruiker is ingesteld, wat kan leiden tot onverwachte resultaten voor servergegevens.

import Foundation

// Datum formatteren in specifieke tijdzone
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-tijd: \(tokyoTime)")

// Beschikbare identifiers voor gebruikersselectie
let displayNames: [(String, String)] = TimeZone.knownTimeZoneIdentifiers
    .prefix(20)
    .map { ($0, TimeZone(identifier: $0)!.localizedName(
        for: .generic, locale: .current
    )) }

// Twee tijdzones vergelijken
let london = TimeZone(identifier: "Europe/London")!
let difference = tokyo.secondsFromGMT(for: Date())
    - london.secondsFromGMT(for: Date())
print("Tokio-Londen verschil: \(difference / 3600)h")

// Werken met afkortingenwoordenboek
let knownAbbrevs = TimeZone.abbreviationDictionary
for (abbr, ident) in knownAbbrevs.sorted(by: { $0.key < $1.key }).prefix(5) {
    print("\(abbr) -> \(ident)")
}

Gelokaliseerde naam van de tijdzone via localizedName(for:locale:) retourneert een voor mensen leesbare naam in de opgegeven taal. Voor Europe/Moscow met Russische locale retourneert de methode bijvoorbeeld „Moskou” en met Engelse locale „Moscow Time”. Beschikbare stijlen: .standard (standaardnaam), .daylightSaving (zomertijd) en .shortGeneric (kort).

import Foundation

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

// Controleren of regio in dezelfde dag valt
let isSameDay = Calendar.current.isDate(
    Date(),
    equalTo: Date(),
    toGranularity: .day
)
print("Zelfde dag in verschillende tijdzones: \(isSameDay)")

Serialisatie van de tijdzone-identifier — de beste praktijk voor het opslaan van TimeZone in databases of UserDefaults. Sla de identifier op (een string van het type Europe/Moscow), niet de afwijking in seconden of de afkorting. De afwijking kan veranderen bij DST-wijziging en de afkorting is dubbelzinnig. Herstel: TimeZone(identifier: savedString).

Veelvoorkomende fouten bij het werken met TimeZone

Gebruik van een vaste afwijking in plaats van een tijdzone-identifier — de meest voorkomende fout. TimeZone(secondsFromGMT: 10800) houdt geen rekening met DST, dus voor Europe/Moscow geeft deze constructie in de zomer een afwijking die 1 uur onjuist is. Gebruik altijd de IANA-identifier voor regio’s met zomertijd.

Vergeten nil-afhandeling bij initialisatie van TimeZone(identifier:) — de tweede meest voorkomende fout. Als de gebruiker een identifier met een fout invoert (bijv. „moscow” in plaats van „Europe/Moscow”), retourneert de constructor nil. Zonder afhandeling van de optionele waarde crasht de app met een runtime-fout. Gebruik guard let of TimeZone(identifier:) met een bekende fallback.

Negeren van DST bij het werken met toekomstige datums. TimeZone.secondsFromGMT(for:) — de enige correcte manier om de afwijking voor een specifieke datum te verkrijgen. Gebruik van secondsFromGMT() zonder parameter voor historische of toekomstige datums geeft de afwijking voor het huidige moment, wat mogelijk niet overeenkomt met de werkelijke afwijking op de opgegeven datum, vooral voor regio’s waar DST is afgeschaft of ingevoerd.

Volgens gegevens van Stack Overflow (2024) heeft ongeveer 15% van de vragen over DateFormatter betrekking op onjuiste timeZone-instelling. Een typisch scenario: de server stuurt een datum in UTC, de ontwikkelaar formatteert deze zonder de timeZone van de formatter in te stellen, en de datum wordt weergegeven in de tijdzone van het apparaat, wat verwarring veroorzaakt bij gebruikers uit verschillende regio’s. Regel: stel altijd expliciet de timeZone van de formatter in voor servergegevens.