Question

Javadoc of TimeZone中有弃用警告：

为了与JDK 1.1.x兼容，还支持其他一些三字母时区ID（例如“PST”，“CTT”，“AST”）。但是，它们的使用已被弃用......

它在这里说“其他”，但我看不出它在哪里定义了哪些三字母ID不被弃用。这些记录在哪里吗？

文档中提到

GMT作为后备，因此可以安全地假设这是一个未弃用的ID;但是：

是否已弃用UTC？您打算使用Etc/UTC吗？或者您应该使用GMT？（TimeZone.getTimeZone("UTC").hasSameRules(TimeZone.getTimeZone("GMT")是真的）
CET（中欧时间）是否已被弃用？如果没有，您应该使用什么时区标识符？根据{{3}}，只有一个其他标识符产生相同的规则，即MET（中欧时间）。

还有另一个时区ID，ECT，其显示名称与CET（中欧时间）相同，但不具有相同的规则（我认为它们在某处不同20世纪70年代中期），其规则与Europe/Paris相同。但是，由于它们有不同的规则，两者不可互换。

因此，我的结论是，支持的三个字母ID的最小集合是GMT和CET;但似乎很奇怪，没有记录。有什么想法吗？

我注意到@shmosel建议的可能重复：this demo。这部分涵盖了我的问题;但我问的是更普遍的问题“支持什么（我们怎么知道）”，而不仅仅是“支持X”。

Answer 1

首先，回答您的具体问题：

所有基于缩写的标识符都应被视为已弃用。它们不足以识别保留所有细节的特定时区。例如，您可以查看使用中欧时间here的所有位置。他们中的一些人整年使用CET，其中一些人在冬天使用CET，而在夏天使用CEST。其中，并非所有这些都使用相同的DST过渡日，或者在其历史记录中具有相同的时区偏移。 CET中的信息不足以决定使用哪一套规则。
使用GMT或UTC相对安全，因为这些都是明确的。但是，使用Etc/GMT或Etc/UTC更为正确。如果您只挑选一个，恕我直言，它应该是Etc/UTC。
CET应该被视为已弃用，以及其他缩写。但是，值得注意的是，某些缩写（如CET）来自TZ数据库，而某些（如AST）来自Java的遗留。这种区别很重要，因为只有TZDB才能用于可能在其他地方传输并由非基于Java的系统解释的数据。

特别需要注意的是，即使PST和CST <，也要认识到TZDB中的美国缩写MST和EST NOT EM>是
您应该选择与您的方案相关的基于位置的时区，而不是CET。如果您在谈论法国，请使用Europe/Paris。如果您在谈论波兰，请使用Europe/Warsaw等

接下来，要了解底层TZ Database有多种类型的标识符可供使用：

基于位置，以Area/Locality
的形式
- 例如：America/New_York，Europe/London，Pacific/Honolulu
基于位置，以Area/Region/Locality
的形式
- 例如：America/Argentina/Buenos_Aires，America/Indiana/Knox
Etc命名空间中的管理区域：
- 例如：Etc/UTC，Etc/GMT+2，Etc/GMT-5
- +/-基于POSIX标准，与通常预期的ISO标准相反
- 通常用于海上船舶

它还有几种形式是历史的工件，并且 NOT 应该再次使用：

基于位置，以Country或Country/StateOrRegion
的形式
- 例如：US/Pacific，US/Hawaii，Brazil/East，Canada/Newfoundland，Egypt，Cuba
美国大陆的POSIX标识符：
- 例如：EST5EDT，CST6CDT，MST7MDT，PST8PDT
缩写 - 其中一些
- 例如：EST，EET，PRC，WET

此外，Java之前已将这些标识符扩展为包含其他缩写，这些缩写是 NOT TZ数据库的一部分。我能够找到它们列为here，作为其相应TZ数据库现代标识符的链接：

Link Australia/Darwin ACT 
Link Australia/Sydney AET 
Link America/Argentina/Buenos_Aires AGT 
Link Africa/Cairo ART 
Link America/Anchorage AST 
Link America/Sao_Paulo BET 
Link Asia/Dhaka BST 
Link Africa/Harare CAT 
Link America/St_Johns CNT 
Link America/Chicago CST 
Link Asia/Shanghai CTT 
Link Africa/Addis_Ababa EAT 
Link Europe/Paris ECT 
Link America/New_York EST 
Link Pacific/Honolulu HST 
Link America/Indianapolis IET 
Link Asia/Calcutta IST 
Link Asia/Tokyo JST 
Link Pacific/Apia MIT 
Link America/Denver MST 
Link Asia/Yerevan NET 
Link Pacific/Auckland NST 
Link Asia/Karachi PLT 
Link America/Phoenix PNT 
Link America/Puerto_Rico PRT 
Link America/Los_Angeles PST 
Link Pacific/Guadalcanal SST 
Link Asia/Saigon VST

当然，这些映射可能是也可能没有意见 - 但据报道它们是Java的TZUpdater工具用来继承对这些遗留Java时区缩写的支持。

Answer 2

也许ZoneId可以作为参考。

ZoneId.getAvailableZoneIds().stream()
        .filter(z -> z.length() == 3)
        .forEach(System.out::println);

输出

GMT
CET
UTC
ROK
MET
PRC
WET
UCT
EET

如果您致电ZoneId.of("CST")，则会抛出

java.time.zone.ZoneRulesException: Unknown time-zone ID: CST

不推荐使用哪个三个字母的时区ID？

2 个答案: