在前面也作出了说明，认为夏令时在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年春节的心情，一直压在心头，但最后却发现极其的简单和业务，呵呵