java - 哪些三字母时区 ID 没有被弃用?

标签 java timezone

Javadoc of TimeZone 中有弃用警告:

For compatibility with JDK 1.1.x, some other three-letter time zone IDs (such as "PST", "CTT", "AST") are also supported. However, their use is deprecated...

它在这里说“其他”,但我看不到它在哪里定义了哪些三字母 ID 是不推荐使用的。这些是否记录在任何地方?

GMT 在文档中被提及为后备,因此可以安全地假设它是未弃用的 ID 之一;但是:

  • 是否已弃用 UTC?您打算改用 Etc/UTC 吗?还是应该使用 GMT? (TimeZone.getTimeZone("UTC").hasSameRules(TimeZone.getTimeZone("GMT") 为真)
  • 是否弃用了 CET(欧洲中部时间)?如果不是,您应该改用哪个时区标识符?根据this demo ,只有一个其他标识符产生相同的规则,即 MET(中欧时间)。

    还有另一个时区 ID,ECT,它与 CET(欧洲中部时间)具有相同的显示名称,但没有相同的规则(我认为它们在 1970 年代中期的某个地方有所不同),它与 Europe/Paris 具有相同的规则。但是,由于它们具有不同的规则,因此两者不可互换。

因此,我由此得出的结论是,支持的三字母 ID 的最小集合是 GMTCET;但是没有记录在案似乎很奇怪。有什么想法吗?


我注意到@shmosel 建议的可能重复项:Is "GMT" an Abbreviation in Java TimeZone and if So is it OK to use it? .这部分涵盖了我的问题;但我问的是更笼统的问题“支持什么(以及我们如何知道)”,而不仅仅是“支持 X”。

最佳答案

首先,回答您的具体问题:

  1. 所有基于缩写的标识符都应被视为弃用。它们不足以识别保留所有详细信息的特定时区。例如,您可以查看所有使用欧洲中部时间 here 的位置.他们有的全年都用CET,有的在冬天用CET,夏天用CEST。其中,并非所有这些都使用相同的 DST 转换日,或者在整个历史中都具有相同的时区偏移量。 CET 中的信息不足以决定使用哪组规则。

  2. 使用GMTUTC 是相对安全的,因为它们是明确的。然而,使用 Etc/GMTEtc/UTC 会更正确。如果您只选择一个,恕我直言,它应该是 Etc/UTC

  3. 正如我提到的,
  4. CET 应该与其他缩写一起被视为已弃用。但是,值得注意的是,一些 缩写(如 CET)来自 TZ 数据库,而一些(如 AST)来自 Java 的遗留.这种区别很重要,因为只有 TZDB 对可能在其他地方传输并由非基于 Java 的系统解释的数据有用。

    特别要注意的是,即使 MSTEST

  5. 您应该选择与您的场景相关的基于地区的时区,而不是 CET。如果您谈论的是法国,请使用 Europe/Paris。如果你在谈论波兰,请使用 Europe/Warsaw 等。

接下来,了解底层TZ Database有几种可接受使用的标识符:

  • 基于位置,形式为Area/Locality

    • 例如:美国/纽约欧洲/伦敦太平洋/火奴鲁鲁
  • 基于位置,形式为Area/Region/Locality

    • 例如:美国/阿根廷/布宜诺斯艾利斯美国/印第安纳州/诺克斯
  • 管理区域,在 Etc 命名空间中:

    • 例如:Etc/UTCEtc/GMT+2Etc/GMT-5
    • +/- 基于 POSIX 标准,与通常预期的 ISO 标准相反
    • 常用于海上船舶

它还有几种形式是历史产物,不应再使用:

  • 基于位置,格式为CountryCountry/StateOrRegion

    • 例如:美国/太平洋美国/夏威夷巴西/东部加拿大/纽芬兰埃及, 古巴
  • 美国大陆的 POSIX 标识符:

    • 例如:EST5EDTCST6CDTMST7MDTPST8PDT
  • 缩写 - 总有一些

    • 例如:ESTEETPRCWET

此外,Java 之前已经扩展了这些标识符以包含其他缩写,这些缩写不是 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 时区缩写。

关于java - 哪些三字母时区 ID 没有被弃用?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/59375572/

相关文章:

使用 Integer.parseInt 时出现 Java NumberFormatException

java - 在 Eclipse 中检查单个文件时出错

java - LibGDX, super 马里奥教程

c# 将字符串(不带时区)解析为 DateTime,同时考虑 DST

java - 基于位置的时区检索

java - 从 GWT 解析带有时区的日期

java - 在 java 中使用 Bouncy CaSTLe 进行 block 式 RSA 加密

java - 如果 TRY 错误

ruby-on-rails - 生产和开发之间奇怪的时间不一致

python - 如何在 django 中获取时区感知日期?