为什么不推荐使用Date.getTimezoneOffset？ [英] Why was Date.getTimezoneOffset deprecated?
问题描述
已弃用。从JDK 1.1版开始，由
- （Calendar.get（Calendar.ZONE_OFFSET）+ Calendar.get（Calendar.DST_OFFSET））/（60 * 1000）替换。
Deprecated. As of JDK version 1.1, replaced by -(Calendar.get(Calendar.ZONE_OFFSET) + Calendar.get(Calendar.DST_OFFSET)) / (60 * 1000).
为什么不推荐？是否有更短的方式（Apache Commons？）以小时/分钟的速度获得UTC的偏移量？我有一个Date对象...我应该将它转换为JodaDate吗？
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?
在你问我为什么要UTC偏移量之前 - 只是记录它，没有
And before you ask why I want the UTC offset - it's just to log it, nothing more.
推荐答案
这里有两个问题。
- 为什么不推荐使用Date.getTimezoneOffset？
我认为这是因为几乎所有的Date方法都被弃用，他们的逻辑到日历。我们期望使用通用的设置和获取与参数说明我们需要哪个特定字段。这种方法有一些优点：方法数量少，并且能够在循环中运行setter，每次循环传递不同的字段。我个人使用这种技术很多：它使代码更短，更容易维护。
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 set and get with 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.
- 快捷方式？但是调用
Calendar.get（Calendar.DST_OFFSET）到
Calendar.getTimeZoneOffset（）
据我看到的区别是6个字符。
As far as I can see the difference is 6 characters.
Joda是一个非常强大的库，如果你真的要写很多复杂的日期操作代码切换到它。我个人使用标准的 java.util.Calendar ，没有任何理由使用外部库：好的旧日历对我来说足够好。
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.Calendar and don't see any reason to use external libraries: good old calendar is good enough for me.
这篇关于为什么不推荐使用Date.getTimezoneOffset？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
