在前面也作出了说明,认为夏令时在Java中只是一个原始时间值的附加计算问题 ,可以获取到具体TimeInMillis到不同的时区去换算,例如GMT+0,就会发现仅是夏令时区域自己显象上的变化,而其他地方没有采用夏令时的地区同一个TimeInMillis换算出来就显出原形,并不是真的隐藏于内部的时间走快了,所以,当时也肯定地指出在夏令时的进入和退出的时间点上,对于使用TimeInMillis作为判断的定时器将不会受到任何影响。

    一般意义上来说夏令时需要获得系统级的支持,例如2007年美国变更夏令时法则后,linux操作系统都要打相应的补丁才可以运行正常;根据Java Doc和文档库的说明,Java通过最新的JDK和JRE更新达到类似的想过,因为对于Java程序而言,Java JVM就是自己虚拟的操作系统环境;对于已存在的Java环境,可以使用SUN提供的时区数据更新工具进行更新。

      正常情况下,JAVA如果辨认的时区和夏令时规则与当前地区一致的话,就可以非常完美地解决夏令时问题,不用其他辅助手段。通过TimeZone.getDefault()发现或 System.getProperty("user.timezone")发现当前时区是什么。

     例如,美国东部时间纽约实行了夏令时,其格式串为

[id="America/New_York",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/New_York,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]。其中startMode和endMode,以及其他相应属性指定了夏令时的规则。一般简单的设定夏令时的某个规则,例如3月份的第二个星期天凌晨2:00等,虽然每年的日期不同,但是,背后的规则和规律是一样的。

     在Linux中可以通过TZ环境变量机制和/etc/sysconfig/clock文件配置系统的时区,进而影响Java JVM的初始化。在所研究的系统中,发现在TZ中设置过于复杂的时区数据格式,例如指定了夏令时的进入和退出时间点,则会导致Java JVM初始化时区变得异常。

     在这次的研究的过程中,利用TZ环境变量机制或java -Duser.timezone=xTimeZone直接设置时区值,我认为都不是很好的策略,还是依赖操作系统和Java JVM初始化能够获得完美一致的时区和夏令时识别为最好,任何一个跛脚运行都会在不经意的时候给你麻烦

 

 好久没有照料博客了,这段积累也不多,后面再写一篇关于内存越界的,这个故障影响到了自己2012年春节的心情,一直压在心头,但最后却发现极其的简单和业务,呵呵

Logo

更多推荐