前一阵子更新了系统,鸟枪换炮地装上了WIN7,可是项目却出现了莫名其妙的问题。我这个项目的客户端启动之后会从服务端获取系统时间,然后更新本地时间。但我发现每次启动客户端后,本地时间都会被改为8小时之前。起初我以为是服务器上系统时间错了,也就没管,一直以8小时前的本地时间进行调试。但是当这影响了我的作息时间,导致下班延后给人一种主动加班的表象时,我无法容忍了,决定到服务器上一看究竟。

这一看让我大跌眼镜(好吧,尽管我不带眼镜)——服务器时间是正确的。那问题究竟在哪里呢?于是设置断点,开始调试。当断点运行到

check.setSystemTime(new Date());

时,查看check对象的systemTime字段的值,居然是传说中的格林威治时间——8小时前。。。

也就是说new Date()出来的不是系统时间,是不是时区出问题了呢?一测试,果然。看下面的代码:

Date date = new Date();
System.out.println(date.toString());
Calendar calendar = Calendar.getInstance();
System.out.println(calendar.getTime());
System.out.println(System.getProperty("user.timezone"));
System.out.println(System.getProperty("user.country"));

结果如下:



Wed May 11 02:08:55 CST 2010 Wed May 11 02:08:56 CST 2010 GMT CN



也就是说,系统的时区出现了问题。但是系统时区是完全正确的:

Date java 去掉时区 java代码中时区问题_Date java 去掉时区

问题究竟出在哪里呢?

会是环境不兼容吗?

 

我的JDK是1.5版本,会不会是JDK太旧与WIN7不兼容,于是在获取当前时区时出现异常而默认取到了GMT呢?于是同样的环境在其他机器上测试,居然完全没问题。而且在网上搜索发现,在Java BUG的数据库中也早已有人报告了这个错误(但是一直没有解决),其中有人是XP,有人是2003。看来不是环境的问题了。

会是注册表的问题吗?

我们知道在注册表HLM\software\microsoft\window nt\currentversion\time zones下有关于各个时区的配置,会不会是由于安装了某个程序把这些配置破坏了呢?于是我从没有问题的机器上导出了一份该节点的注册表,导入到我的机器,奇迹出现了。。。

吗?

答案是没有,问题依旧。

会是人品问题吗?

还真有这个可能。同样的环境别人的机器没问题,而我的不行,不是RPWT是什么?但我是不相信宿命的。笼统上说环境大致相同,但肯定会有微小的差别,这种微小的差别是无法测评的。


瞒天过海法

既然在目前的项目中只有我一台机器有这个问题,也许在这台机器上做点手脚就可以漫天过海了。

在Eclipse中打开Run对话框的Arguments选项卡,在VM arguments框的后面加入如下的参数:



-Duser.timezone=Asia/Shanghai



这样在调试或运行程序时,就会先更改时区。由于是本地的配置,不会对其他机器造成影响。

最终“解决方案”

也许重装系统可以解决,但是我懒,不愿重装。那么没有办法,只有升级JDK了。把1.5卸载,安装1.6,修改一下环境变量,再运行之前的程序,OK,整个世界终于清静了。

但是,问题的症结何在?