此问题与tzinfo aka Olson Timezone Database中的标准时区列表有关。
示例1:我注意到使用America / New_York或America / Detroit(称为“示例城市”,请参阅http://www.w3.org/International/docs/timezones/#tzids)而不是US / Eastern。
示例2:在加拿大,山区时区通常被描述为America / Edmonton而不是Canada / Mountain。不列颠哥伦比亚省的部分地区位于山区时间,但他们的时区被指定为America / Edmonton(位于阿尔伯塔省)。
在这些情况下,为什么要使用区域/范例城市选项而不是国家/地区版本?首先必须创建国家/地区版本的原因,但如果它不是首选方式,为什么会这样?
当一个国家/地区有多个时区时,这主要是一个问题。
在某个地方是否有最好的做法说明为什么一个人比另一个人更受欢迎?
(对于谷歌来说,这是一个很难的问题,因为你得到了所有不相关或无益的结果。我能找到的最接近的是Daylight saving time and time zone best practices,但它没有解决这个问题。)
编辑:can 2 timezone be for 1 city?有“因为不是每个人都使用规范的大陆/城市符号作为他们的时区(我倾向于使用旧的美国/太平洋符号,例如 - 仍然支持,但相当于到America / Los_Angeles)。“他断言“美国/太平洋地区”的说法与我的间接假设相矛盾,即它更新,但仍然不是答案。
答案 0 :(得分:2)
随Olson数据库一起分发的Theory
文件包含以下信息:
时区规则文件命名约定尝试取得平衡 在以下目标中:
独特地识别时钟所有的所有国家区域 自1970年以来同意。这对于预期用途至关重要:静态 时钟保持当地的民用时间。
向人类表明该地区的位置。这简化了[ sic ]的使用。
在政治变革的情况下保持健康。这减少了 更新次数和向后兼容性黑客。例如, 通常不使用国家名称,以避免 当各国改名时不相容 (例如Zaire⟶Congo)或当地点改变国家时 (例如香港从英国殖民地到中国)。
可移植到各种实现中。 这促进了该技术的使用。
在整个世界中使用一致的命名约定。 这简化了使用和维护。
此命名约定不适合没有经验的用户使用 自己选择TZ值(虽然他们当然可以检查 并重用现有设置)。经销商应提供 文档和/或简单的选择界面,解释了 名称;请参阅此发行版提供的'tzselect'程序 一个例子。
名称通常具有AREA / LOCATION形式,其中AREA是名称 属于大陆或海洋,LOCATION是特定的名称 该地区内的位置。北美和南美也有同样的看法 地区,'美国'。典型的名字是'Africa / Cairo','America / New_York', 和'太平洋/檀香山'。
以下是用于选择位置名称的一般规则, 按重要性递减顺序:
/
”以外的名称。在文件名组件中,
仅使用ASCII字母,“.
”,“-
”和“_
”。不使用
数字,因为这可能会产生与POSIX的歧义
TZ字符串。文件名组件不得超过14
字符或以“-
”开头。例如,更喜欢'文莱'
到'Bandar_Seri_Begawan'。_
”代表空格。.
',例如更喜欢'St_Helena'
到'St._Helena'。backward
文件中。文件zone.tab
列出了用于命名的地理位置
时区规则文件。它旨在成为一个详尽的清单
地理区域的规范名称。
请注意,tz@iana.org
邮件列表上最近有关'上海偏好北京'指南的争议(2012年8月)。