【原】JAVA时区设置及时区不一致带来的奇葩现象
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了【原】JAVA时区设置及时区不一致带来的奇葩现象，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1852字，纯文字阅读大概需要3分钟。
内容图文
最近项目中实现了一个课程表的功能，核心功能如下：
1、需要记录一周里每天每个时段的课程安排，后台录入
2、课程开始前，需要自动给课程关注者以各种提醒
于是采用了这样的实现方案：
1、录入时间只记录当天的时分秒对应的毫秒数（这样入库的时间实际上是1970-01-01 HH:mm:ss）
2、定时任务根据当天所在的周数查询当天的课程安排，并将课程时间换算成当天的时间（2015-09-08 HH:mm:ss），然后执行提醒的业务
很简单的一个功能，但是因为时区问题出现了以下奇葩现象：
比如1970-01-01 10:00:00被最终换算成了1970-01-01 10:30:00
也就是说每一个入库时间取出后都增加了不多不少半个小时
于是开始看java.util.Date源码，一探究竟，发现有这样一段：
注意到TimeZone.getDefaultRef(),源码如下：
推测很有可能问题出在时区的选择设置上，于是打印出来结果如下：
1、需要记录一周里每天每个时段的课程安排，后台录入
2、课程开始前，需要自动给课程关注者以各种提醒
于是采用了这样的实现方案：
1、录入时间只记录当天的时分秒对应的毫秒数（这样入库的时间实际上是1970-01-01 HH:mm:ss）
2、定时任务根据当天所在的周数查询当天的课程安排，并将课程时间换算成当天的时间（2015-09-08 HH:mm:ss），然后执行提醒的业务
很简单的一个功能，但是因为时区问题出现了以下奇葩现象：
比如1970-01-01 10:00:00被最终换算成了1970-01-01 10:30:00
也就是说每一个入库时间取出后都增加了不多不少半个小时
于是开始看java.util.Date源码，一探究竟，发现有这样一段：
/>Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
--> BaseCalendar cal = getCalendarSystem(year);
if (tzoffset == -1) { // no time zone specified, have to use local
BaseCalendar.Date ldate = (BaseCalendar.Date) cal.newCalendarDate(TimeZone.getDefaultRef());
http://www.CodeHighlighter.com/
--> BaseCalendar cal = getCalendarSystem(year);
if (tzoffset == -1) { // no time zone specified, have to use local
BaseCalendar.Date ldate = (BaseCalendar.Date) cal.newCalendarDate(TimeZone.getDefaultRef());
注意到TimeZone.getDefaultRef(),源码如下：
/>Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
--> public static TimeZone getDefault() {
return (TimeZone) getDefaultRef().clone();
}
/**
* Returns the reference to the default TimeZone object. This
* method doesn‘t create a clone.
*/
static TimeZone getDefaultRef() {
TimeZone defaultZone = defaultZoneTL.get();
if (defaultZone == null) {
defaultZone = defaultTimeZone;
if (defaultZone == null) {
// Need to initialize the default time zone.
defaultZone = setDefaultZone();
assert defaultZone != null;
}
}
// Don‘t clone here.
return defaultZone;
}
http://www.CodeHighlighter.com/
--> public static TimeZone getDefault() {
return (TimeZone) getDefaultRef().clone();
}
/**
* Returns the reference to the default TimeZone object. This
* method doesn‘t create a clone.
*/
static TimeZone getDefaultRef() {
TimeZone defaultZone = defaultZoneTL.get();
if (defaultZone == null) {
defaultZone = defaultTimeZone;
if (defaultZone == null) {
// Need to initialize the default time zone.
defaultZone = setDefaultZone();
assert defaultZone != null;
}
}
// Don‘t clone here.
return defaultZone;
}
推测很有可能问题出在时区的选择设置上，于是打印出来结果如下：
sun.util.calendar.ZoneInfo[id="Asia/Harbin",offset=28800000,dstSavings=0,useDaylight=false,transitions=19,lastRule=null]
果然如此，服务器时区错误，于是指出这个错误，让运维修正的。
不过还是担心运维层面带来类似的错误，于是手动设置了时区：
不过还是担心运维层面带来类似的错误，于是手动设置了时区：
/>Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
--> TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai"));
logger.info("the default timezone info [{}]", TimeZone.getDefault());
http://www.CodeHighlighter.com/
--> TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai"));
logger.info("the default timezone info [{}]", TimeZone.getDefault());
原文：http://www.blogjava.net/iduido/archive/2015/09/08/427204.html
内容总结
以上是互联网集市为您收集整理的【原】JAVA时区设置及时区不一致带来的奇葩现象全部内容，希望文章能够帮你解决【原】JAVA时区设置及时区不一致带来的奇葩现象所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。
来源：【匿名】