哪些三字母时区 ID 未被弃用?
Javadoc 的 Javadoc代码>时区:
为了与 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...
这里说的是其他",但我看不出它在哪里定义了哪些三字母 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
(中欧时间)是否已弃用?如果不是,您应该使用哪个时区标识符?根据 this demo,只有一个其他标识符产生相同的规则,即MET
(中欧时间).
- Is
UTC
deprecated? Are you meant to useEtc/UTC
instead? Or should you be usingGMT
? (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 isMET
(Middle European Time).
还有另一个时区 ID,ECT
,其显示名称与 CET
(中欧时间)相同,但规则不同(I认为它们在 1970 年代中期有所不同),其规则与 Europe/Paris
相同.但是,由于它们的规则不同,因此两者不能互换.
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 建议的可能重复:是GMT"吗?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:
所有基于缩写的标识符都应被视为已弃用.它们不足以识别保留所有细节的特定时区.例如,您可以在此处查看所有使用中欧时间的地点.其中一些全年使用
CET
,一些在冬季使用CET
,而在夏季使用CEST
.其中,并非所有人都使用相同的 DST 过渡日,或者在其整个历史中具有相同的时区偏移量.CET
中没有足够的信息来决定使用哪组规则.
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 useCET
in the winter butCEST
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 inCET
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
.
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.
需要特别注意的是,尽管 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
.如果您在谈论波兰,请使用 Europe/Warsaw
等.
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:
基于位置,格式为
Area/Locality
- 例如:
America/New_York
、Europe/London
、Pacific/Honolulu
基于位置,格式为Area/Region/Locality
- 例如:
America/Argentina/Buenos_Aires
、America/Indiana/Knox
管理区域,在 Etc
命名空间中:
Administrative zones, in the Etc
namespace:
- 例如:
Etc/UTC
、Etc/GMT+2
、Etc/GMT-5
- +/- 基于 POSIX 标准,与通常预期的 ISO 标准相反
- 常用于海上船舶
它还有几种形式是历史的产物,应该不要再使用:
It also has several forms that are an artifact of history, and should NOT be used any more:
基于位置,格式为
Country
或Country/StateOrRegion
- 例如:
US/Pacific
、US/Hawaii
、巴西/东部
、加拿大/纽芬兰
、埃及
,古巴
- Ex:
US/Pacific
,US/Hawaii
,Brazil/East
,Canada/Newfoundland
,Egypt
,Cuba
美国大陆的 POSIX 标识符:
POSIX identifiers in the continental US:
- 例如:
EST5EDT
、CST6CDT
、MST7MDT
、PST8PDT
缩写 - 其中一些
- 例如:
EST
、EET
、PRC
、WET
此外,Java 之前已经扩展了这些标识符,以包含其他缩写,这些缩写是 NOT TZ 数据库的一部分.我能够在 here 中找到它们,作为相应 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.
相关文章