先来看看测试代码:
![](https://i-blog.csdnimg.cn/blog_migrate/6810355c2f78c12e91b7997a8e8c583a.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/6810355c2f78c12e91b7997a8e8c583a.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/6810355c2f78c12e91b7997a8e8c583a.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/a41954a27d6ad96fa2c2cf816e677448.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/1327ab569c1ae82736693a50b8e33378.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/37c8bf68cdc3cc81759c34160776bc53.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/7ff8d92cded7e0ce15e7ca1acc870052.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/6a9c071a08f1dae2d3e1c512000eef41.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/6a9c071a08f1dae2d3e1c512000eef41.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/6a9c071a08f1dae2d3e1c512000eef41.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/6a9c071a08f1dae2d3e1c512000eef41.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/6a9c071a08f1dae2d3e1c512000eef41.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/717446ca04a6125dc5b6b54e0fa14ab4.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/0196c3df5ea9e936f21e9932cca91014.gif)
编译命令:
>javac TestDate.java
执行命令:
>java TestDate
执行结果:
中国标准时间
Mon Jan 01 08:05:52 CST 1900
可以看到,输出的日期比设置的时间多了5分52秒,
经过测试,凡是设置时间范围为[1900-01-01 8:00:00, 1900-01-01 8:05:52)的,都不能正确输出结果。
经过更多的测试,发现与时区设置有关系。上面的class在不同时间下运行结果不一样:
执行命令:
>java -Duser.timezone=CST TestSDF
中央标准时间
Mon Jan 01 08:00:00 CST 1900
>java -Duser.timezone=PRC TestSDF
中国标准时间
Mon Jan 01 08:05:52 CST 1900
上面输出结果中的两个CTS是不同的,一个是“中央标准时间(Center Standard Time)”,另一个是“中国标准时间(China Standard Time)”。可以看到在“中央标准时间”时区运行是正确的。
通过对TimeZone.getAvailableIDs()获得的所有的时区(包括别名)进行测试,只有“中国标准时间”会出现这个问题。
跟踪了一下jdk的源码,发现问题在于sun.util.calendar.ZoneInfo类的getOffsets方法的算法,不过没明白到底是怎么算的,有谁了解这个算法的,麻烦给解释一下。:)
以上问题测试环境:
Windows XP sp2 + jdk 1.4.2_06(jdk 1.5.0_06、1.6.0_02-ea-fastdebug)
Solaris 9 + jdk 1.4.1_01a