今天记录分享一个排查部署到 Linux 上的 web 项目执行的时间和本地系统时间相差 8 小时的问题javascript
环境:redhat 6.5 考虑有规律的时间差可能和时区不一样有关java
[root@localhost ~]# date 2019年 03月 31日 星期日 16:00:32 CST [root@localhost ~]# date -R Sun, 31 Mar 2019 16:00:44 +0800 [root@localhost ~]# date +"%Z %z" CST +0800
从这里能够肯定,系统的时间和时区正常(北京时间,也就是东八区),时区详情请看这里web
2.1 先在 Linux 上某个目录执行 javac ,看 javac 命令是否可用,出现以下显示就能够(中间部分已省略)centos
[root@localhost test]# javac 用法: javac <options> <source files> 其中, 可能的选项包括: -g 生成全部调试信息 -g:none 不生成任何调试信息 -g:{lines,vars,source} 只生成某些调试信息 ...... -X 输出非标准选项的提要 -J<标记> 直接将 <标记> 传递给运行时系统 -Werror 出现警告时终止编译 @<文件名> 从文件读取选项和文件名
2.2 编写测试程序tomcat
import java.util.TimeZone; import java.util.Date; public class time { public static void main(String[] args) { System.out.println("当前时间:"+new Date()); System.out.println("当前默认时区:"+TimeZone.getDefault()); } }
2.3 编译执行jvm
[root@localhost test]# javac time.java [root@localhost test]# ll 总用量 8 -rw-r--r-- 1 root root 780 3月 31 16:02 time.class -rw-r--r-- 1 root root 239 3月 31 16:00 time.java [root@localhost test]# java time 当前时间:Sun Mar 31 08:02:34 CTM 2019 当前默认时区:sun.util.calendar.ZoneInfo[id="GTM",offset=28800000,dstSavings=0,useDaylight=false,transitions=29,lastRule=null]
这里有导其余的包,若是以上命令很差使,则使用以下命令 (中间的点 . 是当前目录的意思)测试
[root@localhost test]# javac -d . time.java [root@localhost test]# ll 总用量 8 -rw-r--r-- 1 root root 780 3月 31 16:03 time.class -rw-r--r-- 1 root root 239 3月 31 11:00 time.java [root@localhost test]# java -cp . time 当前时间:Sun Mar 31 08:02:40 CST 2019 当前默认时区:sun.util.calendar.ZoneInfo[id="GTM",offset=28800000,dstSavings=0,useDaylight=false,transitions=29,lastRule=null]
这里显然 jvm 的时间比系统的时间早了 8 个小时,且是格林威治的时区,因此这里修改 jvm 的时区便可,这里说下,网上查询说 jvm 的时区默认读取的是硬件时区,目录为 /etc/sysconfig/clock (详情),查看以下ui
[root@localhost test]# cat /etc/sysconfig/clock ZONE="Asia/Shanghai"
与网上对比,这里没有下面这两行.net
UTC=false ARC=false
这里看有人说是没有设置 UTC=false 致使的问题,查看资料说 UTC 指定 BIOS 中保存的时间是不是 GMT/UTC 时间,true 表示 BIOS 里面保存的时间是 UTC 时间,false 表示 BIOS 里面保存的时间是本地时间。 加上后有的机器仍是很差使,若是是在 tomcat 下运行的项目,那就重启 tomcat 便可。调试
若是还很差使,还有修改 tomcat 配置文件的方法,欢迎参考以前的文章:Tomcat修改日期的时区
如今问题基本已解决,以上有些内容是客户现场出现的,因此如今记录时也是凭笔记和记忆回忆的,若有误差也请不吝赐教。
文章参考:https://blog.csdn.net/liqinghuiyx/article/details/53333284