为什么 Date.getTimezoneOffset 被弃用了？

Question

Date.getTimezoneOffset的文档说：

已废弃。自JDK 1.1版本起，由-(Calendar.get(Calendar.ZONE_OFFSET) + Calendar.get(Calendar.DST_OFFSET)) / (60 * 1000)代替。

为什么它被弃用了？有没有更短的方式（Apache Commons？）以小时/分钟为单位获取与UTC的偏移量？ 我有一个日期对象...我应该将其转换为JodaDate吗？

在你问为什么我想要UTC偏移之前 - 只是为了记录它，没有其他目的。

- ripper234

---

在我看来，如果涉及Java日期和时间处理，你应该转换到JodaTime。 - pcalcao

因为并非每个时区偏移量都是整数，换句话说，并非每个时区比相邻时区早或晚一小时。请访问http://www.timeanddate.com/worldclock/。 - Gilbert Le Blanc

@GilbertLeBlanc - 它返回分钟，而不是小时。 - ripper234

@pcalcao - 我有一个来自我无法控制的API的Date对象。我无法“切换到JodaTime”。我可以将Date对象封装为JodaTime对象，并使用它...我建议这是可能的答案。 - ripper234

@ripper234：哎呀，谢谢你的纠正。 - Gilbert Le Blanc

Answer 1

这里有两个问题。

1. 为什么Date.getTimezoneOffset被弃用？

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

2. 快捷方式？但是call有什么问题吗？

Calendar.getTimeZoneOffset()与Calendar.get(Calendar.DST_OFFSET)相比较。

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

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

- AlexR

---

我会接受这个观点，即“他们实际上已经弃用了所有的Date方法”。每个人都建议我转换到joda - 请冷静，因为它是我正在使用的API中的日期对象，我现在无法真正改变API，不是吗。 - ripper234

Answer 2

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

- jtahlborn

Answer 3

在从此页面粘贴代码之前，请注意。也许只是我自己的想法，但我认为为了获得以分钟为单位的时区偏移量，您需要执行以下操作：

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的标准偏移量（以毫秒为单位）。这个值不会因为夏令时而改变。例如，对于美国东海岸时区，无论是否使用夏令时，这个字段始终是-6小时。

Calendar.DST_OFFSET 给出了当前的夏令时偏移量（以毫秒为单位）-如果有的话。例如，在一个使用夏令时的国家，在夏季这个字段可能会有+1小时（1000 * 60 * 60毫秒）的值。

- peterh