Java日历的PST时区时间错误？

问题描述：

玩日历和 TimeZone 时，我遇到了奇怪的行为。

Playing around with Calendar and TimeZone I encountered following strange behaviour.

Calendar pstCal = Calendar.getInstance(TimeZone.getTimeZone("PST"));
System.out.println("H: "+ pstCal.get(Calendar.HOUR));

在撰写本文时，根据 http://www.timeanddate.com/time/zones/pst 是上午1:39。但是，上面显示的代码会生成输出 H：2

At the moment of writing this post, PST time according to http://www.timeanddate.com/time/zones/pst is 1:39am. The code shown above however produces output "H: 2"

为什么用2代替1？
仔细查看Calendar实例说明数字2： dstSavings = 3600000，useDaylight = true

但是到目前为止，我仍然了解PST

But what I understood so far, PST stands for Pacific Standard Time, which means time without daylight saving.

为什么Java用这种方式对待 PST 而是正确的还是正确的？它是一个错误？顺便说一句，这个问题不是针对 EST 的-在这里它与 http相对应： //www.timeanddate.com/time/zones/est 。

Why is Java treating PST this way and is it right or is it a BUG ? Btw this problem isn't here for EST - here it corresponds with http://www.timeanddate.com/time/zones/est.

我也看到了Oracle JDK 1.8.0_60和OpenJDK 1.8.0_60的情况。

I saw this happening for Oracle JDK 1.8.0_60 and OpenJDK 1.8.0_60 as well.

答

来自 javadoc ：

三个字母的时区ID

用于与JDK兼容在1.1.x中，还支持其他三个字母的时区ID（例如 PST， CTT， AST）。但是，不赞成使用，因为通常在多个时区使用相同的缩写（例如， CST可以是美国的中央标准时间和中国的标准时间），

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 because the same abbreviation is often used for multiple time zones (for example, "CST" could be U.S. "Central Standard Time" and "China Standard Time"), and the Java platform can then only recognize one of them.

具体来说，Java可能已决定将 PST等同于 America / Los_Angeles；过去，这意味着夏令时在PST和PDT之间交替进行。他们对 EST的决定可能有所不同。出于任何原因。

Specifically, Java may have decided that "PST" was equivalent to "America/Los_Angeles" in the past, which would mean that alternated between PST and PDT for daylight saving time. They may have decided differently about "EST" for whatever reason.

作为时区标识符，缩写是不好的。您仍然会在 display 值中找到它们，包括 timeanddate.com 上的缩写。。但这并不意味着Java会对它们进行相同的解释。

As a time zone identifier, abbreviations are no good. You will still find them in common use in display values, including the abbreviations on timeanddate.com. But that doesn't mean they are interpreted in the same way by Java.

如果您真的想了解为什么 EST为什么要使用技术，和 PST；当被Java解释为时区ID时，在夏令时方面被区别对待，请考虑将 EST， MST和 HST替换为夏时制。仍作为固定偏移时区在tzdb源数据中出于POSIX向后兼容的原因。 PST和 CST；不再在tzdb中列出，因此Java会通过其他一些硬编码映射来解释它们，以实现与Java 1.1的向后兼容性。

If you really want to get technical about why "EST" and "PST" are treated differently with regard to daylight saving time when interpreted by Java as time zone IDs, consider that "EST", "MST", and "HST" are still in the tzdb source data as fixed offset time zones for POSIX backward compatibility reasons. "PST" and "CST" are no longer listed in the tzdb, so Java interprets them through some other hard-coded mapping for their own backwards compatibility with Java 1.1.

Java日历的PST时区时间错误？

相关推荐