java 为什么不推荐使用 Date.getTimezoneOffset？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10486064/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why was Date.getTimezoneOffset deprecated?
提问by ripper234
The documentation for Date.getTimezoneOffsetsays:
Deprecated. As of JDK version 1.1, replaced by -(Calendar.get(Calendar.ZONE_OFFSET) + Calendar.get(Calendar.DST_OFFSET)) / (60 * 1000).
已弃用。从 JDK 1.1 版开始，替换为 -(Calendar.get(Calendar.ZONE_OFFSET) + Calendar.get(Calendar.DST_OFFSET)) / (60 * 1000)。
Why was it deprecated? Is there a shorter way (Apache Commons?) to get the offset from UTC in hours/minutes? I have a Date object ... should I convert it to JodaDate for this?
为什么它被弃用？有没有更短的方法（Apache Commons？）以小时/分钟为单位从UTC获取偏移量？我有一个 Date 对象……我应该为此将它转换为 JodaDate 吗？
And before you ask why I want the UTC offset - it's just to log it, nothing more.
在你问为什么我想要 UTC 偏移量之前 - 它只是记录它，仅此而已。
回答by AlexR
There are 2 questions here.
这里有2个问题。
- Why was Date.getTimezoneOffset deprecated?
- 为什么不推荐使用 Date.getTimezoneOffset？
I think it is because they actually deprecated nearly all methods of Date and moved their logic to calendar. We are expected to use generic setand getwith the parameter that says which specific field we need. This approach has some advantages: less number of methods and the ability to run setters in a loop passing a different field each time. I personally used this technique a lot: it makes code shorter and easier to maintain.
我认为这是因为他们实际上弃用了几乎所有 Date 方法并将其逻辑移至日历。我们应该使用泛型set和get说明我们需要哪个特定字段的参数。这种方法有一些优点：方法数量较少，并且能够在每次传递不同字段的循环中运行 setter。我个人经常使用这种技术：它使代码更短且更易于维护。
- Shortcut? But what's wrong with call
- 捷径？但是打电话有什么问题
Calendar.get(Calendar.DST_OFFSET)comparing to
Calendar.getTimeZoneOffset()
Calendar.get(Calendar.DST_OFFSET)比较
Calendar.getTimeZoneOffset()
As far as I can see the difference is 6 characters.
据我所知，差异是 6 个字符。
Joda is a very strong library and if you really have to write a lot of sophisticated date manipulation code switch to it. I personally use the standard java.util.Calendarand don't see any reason to use external libraries: good old calendar is good enough for me.
Joda 是一个非常强大的库，如果您真的必须编写大量复杂的日期操作代码，请切换到它。我个人使用该标准java.util.Calendar并且看不到任何使用外部库的理由：好的旧日历对我来说已经足够了。
回答by jtahlborn
All of the date manipulation logic was moved out of Dateonce the Java implementers realized that it might need to be implemented differently for different types of calendars (hence the need to use a GregorianCalendarto retrieve this info now). A Dateis now just a wrapper around a UTC time value.
Date一旦 Java 实现者意识到对于不同类型的日历可能需要以不同的方式实现它（因此现在需要使用 aGregorianCalendar来检索此信息），所有日期操作逻辑都被移出。ADate现在只是 UTC 时间值的包装器。
回答by peterh
Take care before you paste code from this page. Perhaps just me but I believe that in order to get the tz offset in minutes you need to do
在粘贴此页面中的代码之前要小心。也许只是我，但我相信为了在几分钟内获得 tz 偏移量，你需要做
int tzOffsetMin = (cal.get(Calendar.ZONE_OFFSET) + cal.get(Calendar.DST_OFFSET))/(1000*60);
rather than what the Javadoc says, which is:
而不是 Javadoc 所说的，即：
int tzOffsetMin = -(cal.get(Calendar.ZONE_OFFSET) + cal.get(Calendar.DST_OFFSET))/(1000*60);
Calendar.ZONE_OFFSETgives you the standard offset (in msecs) from UTC. This doesn't change with DST. For example for US East Coast timezone this field will always be -6 hours regardless of DST.
Calendar.ZONE_OFFSET为您提供与 UTC 的标准偏移量（以毫秒为单位）。这不会随着夏令时而改变。例如，对于美国东海岸时区，无论夏令时如何，此字段始终为 -6 小时。
Calendar.DST_OFFSETgives you the current DST offset (in msecs) - if any. For example during summer in a country that uses DST this field is likely to have the value +1 hour (1000*60*60 msecs).
Calendar.DST_OFFSET为您提供当前的 DST 偏移量（以毫秒为单位） - 如果有的话。例如，在使用 DST 的国家/地区的夏季，此字段的值可能为 +1 小时（1000*60*60 毫秒）。
