为什么不推荐使用 Date.getTimezoneOffset？答案

【问题标题】：Why was Date.getTimezoneOffset deprecated?为什么不推荐使用 Date.getTimezoneOffset？
【发布时间】：2012-05-16 04:42:14
【问题描述】：

已弃用。从 JDK 1.1 版开始，替换为 -(Calendar.get(Calendar.ZONE_OFFSET) + Calendar.get(Calendar.DST_OFFSET)) / (60 * 1000)。

为什么它被弃用了？是否有更短的方法（Apache Commons？）以小时/分钟获得UTC的偏移量？我有一个 Date 对象...我应该为此将它转换为 JodaDate 吗？

在你问我为什么想要 UTC 偏移量之前 - 只是记录它，仅此而已。

【问题讨论】：

您应该切换到 JodaTime 来处理与 Java 恕我直言的日期和时间处理相关的任何事情。
因为不是每个时区偏移量都是整数。换句话说，并非每个时区都比相邻时区早或晚一个小时。查看timeanddate.com/worldclock
@GilbertLeBlanc - 它返回分钟，而不是小时。
@pcalcao - 我有一个来自我无法控制的 API 的 Date 对象。我不能“将其切换到 JodaTime”。我可以获取 Date 对象，将其包装为 JodaTime 对象，然后使用它……我建议将其作为可能的答案。
@ripper234：哎呀。谢谢指正。

【解决方案1】：

这里有 2 个问题。

我认为这是因为他们实际上弃用了几乎所有 Date 方法并将其逻辑移至日历。我们应该使用通用的set 和get 以及我们需要哪个特定字段的参数。这种方法有一些优点：方法数量较少，并且能够在每次传递不同字段的循环中运行设置器。我个人经常使用这种技术：它使代码更短且更易于维护。

Calendar.get(Calendar.DST_OFFSET) 比较 Calendar.getTimeZoneOffset()

据我所知，区别是 6 个字符。

Joda 是一个非常强大的库，如果您真的需要编写大量复杂的日期操作代码，请切换到它。我个人使用标准 java.util.Calendar 并且看不到任何使用外部库的理由：好的旧日历对我来说已经足够了。

【讨论】：

我会为they actually deprecated all methods of Date 接受这个。每个人都建议我切换到 joda - 请冷静一下，这是我正在使用的 API 中的一个日期对象，我现在真的不能更改 API，可以吗？

【解决方案2】：

在从该页面粘贴代码之前请注意。也许只有我，但我相信为了在几分钟内获得 tz 偏移量，您需要这样做

int tzOffsetMin = (cal.get(Calendar.ZONE_OFFSET) + cal.get(Calendar.DST_OFFSET))/(1000*60);

而不是 Javadoc 所说的：

int tzOffsetMin = -(cal.get(Calendar.ZONE_OFFSET) + cal.get(Calendar.DST_OFFSET))/(1000*60);

Calendar.ZONE_OFFSET 为您提供与 UTC 的标准偏移量（以毫秒为单位）。这不会随着夏令时而改变。例如，对于美国东海岸时区，无论 DST 如何，此字段始终为 -6 小时。

Calendar.DST_OFFSET 为您提供当前 DST 偏移量（以毫秒为单位） - 如果有的话。例如，在使用 DST 的国家/地区的夏季，该字段的值可能为 +1 小时（1000*60*60 毫秒）。

【讨论】：

【解决方案3】：

一旦 Java 实现者意识到可能需要针对不同类型的日历以不同方式实现它（因此现在需要使用 GregorianCalendar 来检索此信息），所有日期操作逻辑都已从 Date 中移出. Date 现在只是一个 UTC 时间值的包装器。

【讨论】：