9

Date.getTimezoneOffset的文档说：

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

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

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

4

3 回答 3

11

这里有2个问题。

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

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

  1. 捷径？但是打电话有什么问题

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

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

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

于 2012-05-07T17:35:42.490 回答
3

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

于 2012-05-07T17:28:55.400 回答
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 毫秒）。

于 2013-03-08T09:30:33.313 回答