为何TimeZone与NSTimeZone的API存在显著差异？

两者的核心差异源于语言设计背景和API设计理念的不同：NSTimeZone是Objective-C时代的面向对象类，而TimeZone是Swift原生的结构体，遵循Swift的类型安全、值语义和明确性原则，因此在API设计上做了针对性调整。

具体差异解析： #

1. 初始化方法的区别

   • NSTimeZone的init(name: String)属于Objective-C时期的设计，它可以灵活接受时区标识符（如"America/New_York"）或时区缩写（如"EST"），但语义不够明确。
   • Swift的TimeZone没有直接对应init(name:)，而是拆分出两个语义更清晰的初始化方法：
     • init(identifier: String?)：设计初衷是接收标准IANA时区标识符，不过底层兼容了时区缩写的解析（也就是你提到的能识别缩写的情况）；
     • init(abbreviation: String?)：专门用于处理时区缩写，职责划分更明确。

2. abbreviation的差异

   • NSTimeZone的abbreviation是属性，默认返回当前系统时间下的时区缩写，但这种设计存在隐式依赖——结果会随夏令时切换等时间变化而改变（比如同一时区可能在不同日期显示EST或EDT）。
   • Swift的TimeZone把abbreviation设计成接收Date参数的方法（func abbreviation(for date: Date) -> String?），且不允许传nil，这是为了明确依赖关系：必须指定具体日期，才能获取对应时间点的时区缩写，避免了隐式依赖当前时间带来的意外行为，同时符合Swift对非可选参数的安全要求。

关于TimeZone(identifier:)能解析缩写的说明 #

这是Swift桥接Objective-C时的兼容行为——底层实际调用了NSTimeZone的init(name:)实现，因此支持缩写解析。但从Swift的API设计意图来说，更推荐用init(abbreviation:)处理时区缩写，init(identifier:)优先用于标准时区标识符。

内容的提问来源于stack exchange，提问作者Anton Tropashko