一、知識掃盲

JDBC：全稱是java DataBase Connectivity
中文意思是java資料庫連線
解釋就是用於java程式語言和資料庫之間的資料庫無關的標準java API

二、錯誤展示

錯誤不好描述，直接看圖：

三、分析原因

在伺服器上執行“date”，看到時間，看到有CST字樣
[[email protected] ~]# date
Wed Jan 9 21:54:23 CST 2019
繼續知識點掃盲：
CST時區
名為CST的時區是一個很混亂的時區，有四種含義：

美國中部時區Central Standard Time（USA）UTC-06：00
澳大利亞中部時區中央標準時間（澳大利亞）UTC + 09:30
中國標準時中國標準時區UTC + 08:00
古巴標準時古巴標準時區UTC-04：00

原因：CST的時區是一個很混亂的時區，在與MySQL協商會話時區時，Java會誤以為是CST -0500或者CST -0600，而非CST +0800

解釋原因是什麼意思：
先來了解下美國的時區變化歷史，美國規定每年從“3月11日”至“11月7日”實行夏令時，美國中部時區改為UTC-05：00；而“11月7日”至“3月11日”實行冬令時，美國中部時區改為UTC-06：00，博主的線上問題發現的時間是2019年1月9日，而此時美國中部的時區是UTC0600，而我們的時區是UTC0800，所以6+8=14個小時，因此線上的錯誤時間相隔14個小時。

四、排錯過程

在專案中，偶然發現數據庫中儲存的 Timestamp 欄位的 unix_timestamp() 值比真實值少了 14 個小時。通過除錯追蹤，發現了 com.mysql.cj.jdbc 裡的時區協商有問題。
當 JDBC 與 MySQL 開始建立連線時，會呼叫 com.mysql.cj.jdbc.ConnectionImpl.initializePropsFromServer() 獲取伺服器引數，其中我們看到呼叫 this.session.configureTimezone() 函式，它負責配置時區。

public void configureTimezone() {
    String configuredTimeZoneOnServer = getServerVariable("time_zone");

    if ("SYSTEM".equalsIgnoreCase(configuredTimeZoneOnServer)) {
        configuredTimeZoneOnServer = getServerVariable("system_time_zone");
    }

    String canonicalTimezone = getPropertySet().getStringReadableProperty(PropertyDefinitions.PNAME_serverTimezone).getValue();

    if (configuredTimeZoneOnServer != null) {
        // user can override this with driver properties, so don't detect if that's the case
        if (canonicalTimezone == null || StringUtils.isEmptyOrWhitespaceOnly(canonicalTimezone)) {
            try {
                canonicalTimezone = TimeUtil.getCanonicalTimezone(configuredTimeZoneOnServer, getExceptionInterceptor());
            } catch (IllegalArgumentException iae) {
                throw ExceptionFactory.createException(WrongArgumentException.class, iae.getMessage(), getExceptionInterceptor());
            }
        }
    }

    if (canonicalTimezone != null && canonicalTimezone.length() > 0) {
        this.serverTimezoneTZ = TimeZone.getTimeZone(canonicalTimezone);

        // The Calendar class has the behavior of mapping unknown timezones to 'GMT' instead of throwing an exception, so we must check for this...
        if (!canonicalTimezone.equalsIgnoreCase("GMT")
            && this.serverTimezoneTZ.getID().equals("GMT")) {
            throw ...
        }
    }

    this.defaultTimeZone = this.serverTimezoneTZ;
}
 

追蹤程式碼可知，當 MySQL 的 time_zone 值為 SYSTEM 時，會取 system_time_zone 值作為協調時區。
讓我們登入到 MySQL 伺服器驗證這兩個值：

mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CST    |
| time_zone        | SYSTEM |
+------------------+--------+
2 rows in set (0.00 sec)

重點在這裡！若 String configuredTimeZoneOnServer 得到的是 CST 那麼 Java 會誤以為這是 CST -0600 ，因此 TimeZone.getTimeZone(canonicalTimezone) 會給出錯誤的時區資訊。debug variables
本機預設時區是 Asia/Shanghai +0800 ，誤認為伺服器時區為 CST -0600 ，實際上伺服器是 CST +0800 。

我們會想到，即便時區有誤解，如果 Timestamp 是以 long 表示的時間戳傳輸，也不會出現問題，下面讓我們追蹤到 com.mysql.cj.jdbc.PreparedStatement.setTimestamp()

public void setTimestamp(int parameterIndex, Timestamp x) throws java.sql.SQLException {
    synchronized (checkClosed().getConnectionMutex()) {
        setTimestampInternal(parameterIndex, x, this.session.getDefaultTimeZone());
    }
}

注意到這裡 this.session.getDefaultTimeZone() 得到的是剛才那個 CST -0600

private void setTimestampInternal(int parameterIndex, Timestamp x, TimeZone tz) throws SQLException {
    if (x == null) {
        setNull(parameterIndex, MysqlType.TIMESTAMP);
    } else {
        if (!this.sendFractionalSeconds.getValue()) {
            x = TimeUtil.truncateFractionalSeconds(x);
        }

        this.parameterTypes[parameterIndex - 1 + getParameterIndexOffset()] = MysqlType.TIMESTAMP;

        if (this.tsdf == null) {
            this.tsdf = new SimpleDateFormat("''yyyy-MM-dd HH:mm:ss", Locale.US);
        }

        this.tsdf.setTimeZone(tz);

        StringBuffer buf = new StringBuffer();
        buf.append(this.tsdf.format(x));
        if (this.session.serverSupportsFracSecs()) {
            buf.append('.');
            buf.append(TimeUtil.formatNanos(x.getNanos(), true));
        }
        buf.append('\'');

        setInternal(parameterIndex, buf.toString());
    }
}

原來 Timestamp 被轉換為會話時區的時間字串了。問題到此已然明晰：

JDBC 誤認為會話時區在 CST-6
JBDC 把 Timestamp+0 轉為 CST-6 的 String-6
MySQL 認為會話時區在 CST+8，將 String-6 轉為 Timestamp-14

最終結果相差 14個小時！如果處在夏令時還會相差 13個小時

五、解決方法

解決辦法非常的簡單，手動明確指定 MySQL 資料庫的時區，不使用引發誤解的 CST：
臨時生效：
mysql> set global time_zone = '+08:00';
Query OK, 0 rows affected (0.00 sec)

mysql> set time_zone = '+08:00';
Query OK, 0 rows affected (0.00 sec)

永久生效（修改後需要重啟mysql）：
修改 my.cnf 檔案，在 [mysqld] 節下增加 default-time-zone = '+08:00'