不推荐使用哪个三个字母的时区ID? [英] Which three-letter time zone IDs are not deprecated?

查看:200
本文介绍了不推荐使用哪个三个字母的时区ID?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Javadoc中有一个弃用警告 TimeZone


为了与JDK 1.1.x兼容,有些还支持其他三个字母的时区ID(例如PST,CTT,AST)。但是,它们的使用已被弃用......

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...

它在这里说其他,但我看不出它在哪里定义哪三个-letter ID不推荐使用。这些是在任何地方记录的吗?

It says "other" here, but I can't see where it defines which three-letter IDs are non-deprecated. Are these documented anywhere?

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

GMT is mentioned in the doc as the fallback, so it's safe to assume that's one of non-deprecated IDs; but:


  • UTC 是否已弃用?您打算使用 Etc / UTC 吗?或者你应该使用 GMT ? ( TimeZone.getTimeZone(UTC)。hasSameRules(TimeZone.getTimeZone(GMT)为真)

  • CET (中欧时间)是否已弃用?如果不是,您应该使用哪个时区标识符?根据此演示,只有一个其他标识符产生相同的规则,即 MET (中欧时间)。

  • Is UTC deprecated? Are you meant to use Etc/UTC instead? Or should you be using GMT? (TimeZone.getTimeZone("UTC").hasSameRules(TimeZone.getTimeZone("GMT") is true)
  • Is CET (Central European Time) deprecated? If not, what time zone identifier are you supposed to use instead? According to this demo, there is only one other identifier yielding the same rules, which is MET (Middle European Time).

还有另一个时区ID, ECT ,其显示名称与 CET相同(中欧时间),但没有相同的规则(我认为它们在20世纪70年代中期有所不同),其规则与欧洲/巴黎<相同/ code>。但是,由于它们有不同的规则,两者不可互换。

There is another timezone ID, ECT, which has the same display name as CET (Central European Time), but which doesn't have the same rules (I think they differ somewhere in the mid 1970s), which has the same rules as Europe/Paris. But, since they have different rules, the two are not interchangable.

所以,我的结论是,支持的三个字母ID的最小集合是 GMT CET ;但它似乎很奇怪没有记录。任何想法?

So, my conclusion from this is that the minimal set of supported three-letter IDs is GMT and CET; but it seems odd that is not documented. Any ideas?

我注意到@shmosel建议的可能重复: IsGMT" Java TimeZone中的缩写,如果可以,可以使用它吗?。这部分涵盖了我的问题;但我问的是更普遍的问题支持什么(我们怎么知道),而不仅仅是支持X。

I note the possible duplicate suggested by @shmosel: Is "GMT" an Abbreviation in Java TimeZone and if So is it OK to use it?. That partly covers my question; but I'm asking the more general question "what is supported (and how do we know that)", rather than just "is X supported".

推荐答案

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

First, to answer your specific questions:


  1. 所有基于缩写的标识符都应被视为已弃用。它们不足以识别保留所有细节的特定时区。例如,您可以查看使用中欧时间此处的所有位置。他们中的一些人整年都使用 CET ,其中一些人在冬天使用 CET ,但 CEST 夏天。其中,并非所有人都使用相同的DST过渡日,或者在他们的历史中具有相同的时区偏移。在 CET 中没有足够的信息来决定使用哪一套规则。

  1. All abbreviation-based identifiers should be considered deprecated. They are not sufficient to identify a particular time zone with all detail retained. For example, you can see all the locations that use Central European Time here. Some of them use CET all year long, and some of them use CET in the winter but CEST in the summer. Of those, not all of them use the same DST transition days, or have the same time zone offsets throughout their history. There's just not enough information in CET to decide which set of rules to use.

这是相对的安全使用 GMT UTC ,因为这些都是明确的。但是,使用 Etc / GMT Etc / UTC 更为正确。如果您只挑选一个,恕我直言,它应该是 Etc / UTC

It is relatively safe to use GMT or UTC, as these are unambiguous. However it would be more correct to use Etc/GMT or Etc/UTC. If you were to pick just one, IMHO it should be Etc/UTC.

<$ c如上所述,$ c> CET 应该被视为已弃用,以及其他缩写。但是,值得注意的是一些缩写(如 CET )来自TZ数据库,还有一些(如 AST )来自Java的遗产。这种区别很重要,因为只有TZDB才能用于可能在其他地方传输并由非基于Java的系统解释的数据。

CET should be considered deprecated, along with other abbreviations, as I mentioned. However, it's worth noting that some abbreviations (like CET) come from the TZ Database, and some (like AST) come from legacy of Java. This distinction is important, as only the TZDB ones are useful in data that may be transmitted elsewhere and interpreted by non-Java based systems.

特别注意,要认识到美国缩写 PST CST 在TZDB中 NOT ,即使 MST EST

Of particular note, recognize that the US abbreviations PST and CST are NOT in the TZDB, even though MST and EST are.

而不是 CET ,您应该选择与您的方案相关的基于位置的时区。如果您正在谈论法国,请使用 Europe / Paris 。如果您在谈论波兰,请使用欧洲/华沙等。

Instead of CET, you should pick which locality-based time zone is relevant to your scenario. If you are talking about France, use Europe/Paris. If you are talking about Poland, use Europe/Warsaw, etc.

接下来,了解基础 TZ数据库有几种类型的标识符是可以接受的使用:

Next, understand that the underlying TZ Database has several types of identifiers that are acceptable to use:


  • 基于位置,以区域/地区


  • 例如: America / New_York 欧洲/伦敦太平洋/檀香山

  • Ex: America/New_York, Europe/London, Pacific/Honolulu

基于位置,以区域/地区/地区的形式


  • Ex: America / Argentina / Buenos_Aires America / Indiana / Knox

  • Ex: America/Argentina/Buenos_Aires, America/Indiana/Knox

管理区域,在 Etc 命名空间中:

Administrative zones, in the Etc namespace:


  • 例如: Etc / UTC Etc / GMT + 2 Etc / GMT-5

  • +/-基于POSIX标准,与通常预期的ISO相反标准

  • 通常用于海上船舶

  • Ex: Etc/UTC, Etc/GMT+2, Etc/GMT-5
  • +/- are based on POSIX standards, opposite of the typically expected ISO standard
  • Commonly used for ships at sea

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

It also has several forms that are an artifact of history, and should NOT be used any more:


  • 基于位置,以国家/地区或国家/州或地区的形式


  • 例如:美国/太平洋美国/夏威夷巴西/东部加拿大/纽芬兰埃及古巴

  • Ex: US/Pacific, US/Hawaii, Brazil/East, Canada/Newfoundland, Egypt, Cuba

美国大陆的POSIX标识符:

POSIX identifiers in the continental US:


  • 例如: EST5EDT CST6CDT MST7MDT PST8PDT

  • Ex: EST5EDT, CST6CDT, MST7MDT, PST8PDT

缩写 - 其中一些


  • 例如: EST EET PRC WET

  • Ex: EST, EET, PRC, WET

此外,Java之前已将这些标识符扩展为包含广告属于TZ数据库的 NOT 的ditional缩写。我能够找到它们列为这里,作为其相应TZ数据库的链接现代标识符:

Additionally, Java had previously extended these identifiers to include additional abbreviations that are NOT part of the TZ Database. I was able to find them listed here, as links to their corresponding TZ Database modern identifiers:

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时区缩写的支持。

Of course, these mappings may or may not be opinionated - but they are reportedly the ones used by Java's TZUpdater tool to carry forward support for these legacy Java time zone abbreviations.

这篇关于不推荐使用哪个三个字母的时区ID?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆