今天記錄分享一個排查部署到 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