TimeZone — 这是什么，Foundation 类和时区

Foundation 中的 TimeZone 是什么？

TimeZone — 是 Swift 中的一种值类型，提供关于地理时区的信息：相对于 UTC 的偏移、名称、缩写和夏令时转换规则。在 Objective-C 中，该类名为 NSTimeZone。两个类都基于 IANA Time Zone Database（也称为 Olson 数据库），该数据库包含自 1970 年以来时区变更的历史记录。

每个 TimeZone 实例存储一个时区标识符（例如 Europe/Moscow）、当前相对于 UTC 的偏移（以秒为单位）、isDaylightSavingTime 标志和下一次转换的日期。标识符是主键：在初始化 TimeZone(identifier:) 时，系统从设备的时区数据库中加载相应的记录。

根据 IANA (2024) 的数据，该数据库包含超过 600 个唯一的时区标识符。Apple 在每个 iOS 和 macOS 版本中都提供了该数据库的一部分，从而保证所有设备上计算的一致性，无需网络请求。

TimeZone 在 iOS 和 macOS 中如何工作？

架构 — Foundation 中的 TimeZone 基于两层系统构建：时区标识符（人类可读的名称）和其数值表示（相对于 UTC 的偏移）。系统从设备设置中自动选择当前时区，但开发者可以为特定的格式化操作覆盖它。

TimeZone 与 Calendar 和 DateFormatter 紧密关联。在格式化日期时，DateFormatter 使用 TimeZone 实例的 timeZone 属性将绝对时间瞬间（Date）转换为适当时区中的文本表示。如果未设置 timeZone，则使用系统默认时区 — TimeZone.current。

TimeZone 实例的类型

重要细节： TimeZone(identifier:) 为未知标识符返回 nil。这是应用程序崩溃的常见原因 — 开发者忘记处理可选值，从用户输入中传递错误的标识符。对于 IANA 标识符，大小写很重要：Europe/Moscow — 正确，europe/moscow — nil。

时区标识符的格式

IANA Time Zone Database 使用 "区域/城市" (Continent/City) 格式，其中区域是大陆之一（Africa、America、Asia、Atlantic、Australia、Europe、Indian、Pacific）或洋，城市是时区范围内最大的居民点。这种格式保证了标识符的唯一性和可读性。

除了主要格式外，TimeZone 还支持三种额外的识别方法：缩写（MSK、EST、PST）、三字母时区代码（GMT、UTC）和数值偏移（+0300、-0500）。但缩写是含糊的：EST 可以指 Eastern Standard Time (GMT-5)，也可以指澳大利亚的 Eastern Summer Time (GMT+10)。Apple 建议仅使用 IANA 标识符。

import Foundation

// 获取所有已知的时区标识符
let allIdentifiers: [String] = TimeZone.knownTimeZoneIdentifiers
print("时区总数：\(allIdentifiers.count)")

// 按地区筛选
let europeZones = allIdentifiers.filter { $0.hasPrefix("Europe/") }
print("欧洲时区：\(europeZones)")

// 缩写（不推荐用于生产）
if let moscowTimeZone = TimeZone(abbreviation: "MSK") {
    print("从 GMT 到 MSK 的秒数：\(moscowTimeZone.secondsFromGMT())")
}

// 按偏移查找标识符
let utcPlus3 = TimeZone(secondsFromGMT: 10800)
print("标识符：\(utcPlus3.identifier)")

缩写 在 TimeZone.abbreviationDictionary 中包含所有已知时区的缩写，但该字典不保证唯一性：键 PST 可能对应 America/Los_Angeles 或 Pacific/Pago_Pago。在生产代码中，始终使用 IANA 标识符。

夏令时转换和 TimeZone

TimeZone自动考虑所有实行夏令时和冬令时的地区的 DST（Daylight Saving Time）。系统使用来自 IANA Time Zone Database 的历史数据，该数据库包含每个时区的精确转换日期。isDaylightSavingTime 属性在时区当前处于夏令时时返回 true。

nextDaylightSavingTimeTransition 方法允许您查看下一次转换的日期，这对于规划未来事件很有用。这一功能对于 DST 规则经常变化的地区（如巴西或摩洛哥）尤为重要 — 直到 2024 年，巴西每年都改变转换日期，手动计算导致应用程序中的错误。

根据 Apple WWDC 2023 的数据，作为 Foundation 基础的 ICU (International Components for Unicode) 库在每次 iOS 更新时都会更新 DST 数据。应用程序不应将夏令时数据缓存超过系统更新后的一天 — IANA 数据库可能通过时区调整而不更新操作系统版本就变化。

import Foundation

// 检查 Europe/Moscow 的 DST
let moscow = TimeZone(identifier: "Europe/Moscow")!
let now = Date()
let isMoscowDST = moscow.isDaylightSavingTime(for: now)
print("莫斯科当前处于 DST：\(isMoscowDST)")

// 获取下一次 DST 转换日期
if let nextTransition = moscow.nextDaylightSavingTimeTransition(
    after: now
) {
    let dstOffset = moscow.daylightSavingTimeOffset(
        for: nextTransition
    )
    print("下一次转换：\(nextTransition)，DST 偏移：\(dstOffset)s")
}

// 带有 DST 意识的安全转换
let newYork = TimeZone(identifier: "America/New_York")!
let offsetNY = newYork.secondsFromGMT(for: now)
print("NY 当前偏移：\(offsetNY / 3600)h")

关键细节： secondsFromGMT(for:) 考虑指定日期的 DST，而 secondsFromGMT() 仅考虑当前时间。在格式化历史日期时，始终使用带 Date 参数的版本：secondsFromGMT(for: someHistoricalDate)。差异可能高达 1–2 小时，这对于日志或历史数据至关重要。

Swift 中的 TimeZone：代码示例

使用特定时区格式化日期 — 这是使用 TimeZone 时最常见的任务。DateFormatter 使用 timeZone 属性将 Date 转换为文本。如果未显式设置 timeZone，格式化器将使用 TimeZone.current — 用户设备上设置的时区，这可能导致服务器数据出现意料之外的结果。

import Foundation

// 在特定时区中格式化日期
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("东京时间：\(tokyoTime)")

// 用于用户选择的可用标识符
let displayNames: [(String, String)] = TimeZone.knownTimeZoneIdentifiers
    .prefix(20)
    .map { ($0, TimeZone(identifier: $0)!.localizedName(
        for: .generic, locale: .current
    )) }

// 比较两个时区
let london = TimeZone(identifier: "Europe/London")!
let difference = tokyo.secondsFromGMT(for: Date())
    - london.secondsFromGMT(for: Date())
print("东京-伦敦差异：\(difference / 3600)h")

// 使用缩写字典
let knownAbbrevs = TimeZone.abbreviationDictionary
for (abbr, ident) in knownAbbrevs.sorted(by: { $0.key < $1.key }).prefix(5) {
    print("\(abbr) -> \(ident)")
}

本地化名称 — localizedName(for:locale:) 方法返回指定语言中的人类可读名称。例如，对于 Europe/Moscow ，使用俄语区域时返回 "莫斯科"，使用英语区域时返回 "Moscow Time"。可用的风格有：.standard（标准名称）、.daylightSaving（夏令时）和 .shortGeneric（简短）。

import Foundation

let paris = TimeZone(identifier: "Europe/Paris")!
let nameRU = paris.localizedName(
    for: .standard,
    locale: Locale(identifier: "ru_RU")
)
print("俄语名称：\(nameRU)")

// 检查地区是否在同一天
let isSameDay = Calendar.current.isDate(
    Date(),
    equalTo: Date(),
    toGranularity: .day
)
print("不同时区中的同一天：\(isSameDay)")

序列化 — 存储时区标识符是在数据库或 UserDefaults 中存储 TimeZone 的最佳实践。存储标识符（类似 Europe/Moscow 的字符串），而非以秒为单位的偏移或缩写。偏移可能随 DST 的变化而变化，缩写则含糊不清。恢复：TimeZone(identifier: savedString)。

使用 TimeZone 时的常见错误

使用固定偏移 而非时区标识符 — 最常见的错误。TimeZone(secondsFromGMT: 10800) 不考虑 DST，因此对于 Europe/Moscow 在夏天，该构造会产生 1 小时的错误偏移。始终为实行夏令时的地区使用 IANA 标识符。

忘记处理 nil — 在初始化 TimeZone(identifier:) 时第二常见的错误。如果用户输入错误的标识符（例如“moscow”而非“Europe/Moscow”），构造器返回 nil。如果不处理可选值，应用程序将崩溃并报运行时错误。使用 guard let 或带已知 fallback 的 TimeZone(identifier:)。

在处理未来日期时忽略 DST。 TimeZone.secondsFromGMT(for:) 是获取特定日期偏移的唯一正确方法。对于历史或未来日期使用无参数的 secondsFromGMT() 会返回当前时刻的偏移，这可能与该日期的实际偏移不符，尤其是在已经取消或实施 DST 的地区。

根据 Stack Overflow (2024) 的数据，约 15% 的 DateFormatter 相关问题与 timeZone 的错误设置有关。典型场景：服务器以 UTC 格式发送日期，开发者在没有设置格式化器 timeZone 的情况下格式化它，导致日期显示在设备的时区，引起来自不同地区的用户的混淆。规则：始终为服务器数据显式设置格式化器的 timeZone。