https://blog.csdn.net/yin138/article/details/52765089
CentOS7修改时区的正确姿势
今天在CentOS7上运行Java程序,发现程序生成的时间与当前时间匹配不上,还以为是数据停止更新了,后来发现没有正确使用修改时区的姿势,导致程序时区错误。
正确的修改CentOS7 时区的姿势:
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime1
其他系统的修改文件可能是/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()); } }12345678
通过如下代码可以简单的Java所读取的时间和时区信息。
通过-Duser.timezone参数修改需要按特定时区运行的java程序,例如:
[root@jfgj-gather-1 bin]# java -Duser.timezone=America/New_York TestTimeZoneTime:Sat Oct 08 23:32:37 EDT 2016TimeZone: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 TestTimeZoneTime:Sun Oct 09 11:32:55 CST 2016TimeZone:sun.util.calendar.ZoneInfo[id="Asia/Shanghai",offset=28800000,dstSavings=0,useDaylight=false,transitions=19,lastRule=null]123456
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/yin138/article/details/52765089