CentOS7修改时区的正确姿势 

今天在CentOS7上运行Java程序，发现程序生成的时间与当前时间匹配不上，还以为是数据停止更新了，后来发现没有正确使用修改时区的姿势，导致程序时区错误。 

正确的修改CentOS7 时区的姿势：

 

ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

 

其他系统的修改文件可能是/var/etc/localtime. 

错误的姿势，通过cp命令覆盖/etc/localtime时间。 

我就是通过百度的结果修改的，导致了悲剧发生。 

通过cp命令修改时区，通过date, data -R命令显示的时区都是正确的，可是对于java程序而言，是错误的，具体原因在于Java访问系统时区的方式上，可参见文章：Java TimeZone 和 Linux TimeZone问题。 

 

该文章很好的说明了Java访问系统时区的方式： 

1. 如有环境变量 TZ设置，则用TZ中设置的时区 

2. 在 /etc/sysconfig/clock文件中找 “ZONE”的值 

3. 如何2)都没，就用/etc/localtime 和 /usr/share/zoneinfo 下的时区文件进行匹配，如找到匹配的，就返回对应的路径和文件名。 

问题在于，如果使用cp命令来修改/etc/localtime文件，那么可能就会导致修改的不是/etc/localtime文件，而是原时区的文件内容. 

/etc/localtime是通过符号链接链接/usr/share/zoneinfo下的文件，而java是通过文件名来确认时区的，data命令是通过文件内容确认时区的，这样就导致了data命令时区正确，而java的时区是错误的. 

 

如上图所示：CentOS7是通过符号链接到/usr/share/zoneinfo/下的时区文件的，如果通过cp指令只会修改原时区文件内容，这样，通过date的系统命令，查看时间是OK的，可是java是通过读取文件名的方式确认时区信息的。所以时区还是纽约。

 

import java.util.Calendar;

 

public class TestTimeZone {

    public static void main(String[] args){

        System.out.println("Time:" + Calendar.getInstance().getTime().toString());

        System.out.println("TimeZone:" + Calendar.getInstance().getTimeZone());

    }

}

 

 

通过如下代码可以简单的Java所读取的时间和时区信息。 

通过-Duser.timezone参数修改需要按特定时区运行的java程序，例如：

 

[root@jfgj-gather-1 bin]# java -Duser.timezone=America/New_York TestTimeZone

Time:Sat Oct 08 23:32:37 EDT 2016

TimeZone:sun.util.calendar.ZoneInfo[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]]

[root@jfgj-gather-1 bin]# java -Duser.timezone=Asia/Shanghai TestTimeZone

Time:Sun Oct 09 11:32:55 CST 2016

TimeZone:sun.util.calendar.ZoneInfo[id="Asia/Shanghai",offset=28800000,dstSavings=0,useDaylight=false,transitions=19,lastRule=null]