connectionTimeZone

設定 Connector/J 使用的連線時區，當需要保留瞬時時間值時，用於 JVM 預設值和目標時區之間的轉換。

接受地理時區名稱或格林威治/UTC 的時區偏移量，使用 'java.time.ZoneId' 能夠剖析的語法，或兩個邏輯值 "LOCAL" 和 "SERVER" 其中之一。預設值為 "LOCAL"。如果設定為明確的時區，則必須是 JVM 或 JVM 和 MySQL 都支援的時區。如果設定為 "LOCAL"，則驅動程式會假設連線時區與 JVM 預設時區相同。如果設定為 "SERVER"，則驅動程式會嘗試從 MySQL 伺服器工作階段變數 'time_zone' 或 'system_time_zone' 上設定的值偵測工作階段時區。時區偵測和隨後對 Java 時區的對應可能會因多種原因而失敗，主要是因為使用時區縮寫，在這種情況下，必須設定明確的時區或在伺服器上設定不同的時區。

此選項本身不會將 MySQL 伺服器工作階段變數 'time_zone' 設定為給定的值。若要執行此操作，'forceConnectionTimeZoneToSession' 連線選項必須設定為 "true"。

請注意，將值設定為 'connectionTimeZone' 並搭配 "forceConnectionTimeZoneToSession=false" 和 "preserveInstants=false" 沒有任何效果，因為在這種情況下，此選項既不用於變更工作階段時區，也不用於基於時間的資料的時區轉換。

先前的連線選項 'serverTimezone' 仍然有效，作為此選項的別名，但未來可能會被取代。

另請參閱 'forceConnectionTimeZoneToSession' 和 'preserveInstants' 以取得更多詳細資訊。

forceConnectionTimeZoneToSession

如果啟用，則將 'connectionTimeZone' 連線屬性所判定的時區值設定為目前伺服器工作階段的 'time_zone' 變數。如果時區值是給定為地理時區，則 Connector/J 會將此值按原樣設定在伺服器工作階段中，在這種情況下，必須事先填入時區系統表（請參閱 MySQL Server 文件以取得更多詳細資訊）；但是，如果值是給定為格林威治/UTC 的偏移量，使用任何支援的語法，則伺服器工作階段時區會設定為 UTC 的數值偏移量。

這樣，當儲存在 TIMESTAMP 資料行時，不需要在 JVM 預設時區和連線時區之間進行中間轉換，即可儲存 'java.sql.Timestamp' 或 'java.time.OffsetDateTime' 等瞬時 Java 物件的正確毫秒值。

請注意，它也會影響 'NOW()'、'CURTIME()' 或 'CURDATE()' 等 MySQL 函數的結果。

如果與 "connectionTimeZone=SERVER" 搭配使用，此選項沒有任何效果，因為在這種情況下，工作階段已設定為所需的時區。

另請參閱 'connectionTimeZone' 和 'preserveInstants' 以取得更多詳細資訊。

noDatetimeStringSync

不要確保 'ResultSet.getTimestamp().toString().equals(ResultSet.getString())'。

preserveInstants

如果啟用，Connector/J 會盡力保留 Java 瞬時型物件（例如 'java.sql.Timestamp' 或 'java.time.OffsetDateTime'）在時間軸上的瞬時點，而不是它們的原始視覺形式。否則，驅動程式會始終使用 JVM 預設時區來呈現傳送至伺服器的值，並從擷取的資料建構 Java 物件。

MySQL 對 TIMESTAMP 值使用隱含的時區轉換：它們會從工作階段時區轉換為 UTC 以進行儲存，並從 UTC 轉換回工作階段時區以進行擷取。因此，為了在內部儲存正確的 UTC 值，驅動程式會在傳送至伺服器之前，將值從原始時區轉換為工作階段時區。在擷取時，Connector/J 會將接收到的值從工作階段時區轉換為 JVM 預設時區。

在儲存時，只有在目標 'SQLType'（明確的或預設的）是 TIMESTAMP 時，才會執行轉換。在擷取時，只有當來源資料行的類型為 TIMESTAMP、DATETIME 或字元類型，且目標類別是瞬時型類別（例如 'java.sql.Timestamp' 或 'java.time.OffsetDateTime'）時，才會執行轉換。

請注意，如果與 "connectionTimeZone=LOCAL" 搭配使用，此選項沒有任何效果，因為在這種情況下，來源和目標時區相同。雖然在這種情況下，如果與 "forceConnectionTimeZoneToSession=true" 一起設定，仍然可以儲存正確的瞬時值。

另請參閱 'connectionTimeZone' 和 'forceConnectionTimeZoneToSession' 以取得更多詳細資訊。

sendFractionalSeconds

如果設定為 "false"，則在將任何資料傳送至伺服器之前，小數秒將始終被截斷。此選項僅適用於預先準備的陳述式、可呼叫的陳述式或可更新的結果集。

sendFractionalSecondsForTime

如果設定為 "false"，則 'java.sql.Time' 的小數秒將依照 JDBC 規格的要求被忽略。如果設定為 "true"，則會以小數秒呈現其值，允許將毫秒儲存到 MySQL TIME 資料行中。此選項僅適用於預先準備的陳述式、可呼叫的陳述式或可更新的結果集。如果 "sendFractionalSeconds=false"，則此選項沒有任何效果。

treatMysqlDatetimeAsTimestamp

驅動程式是否應在 'ResultSet.getObject()' 中將 MySQL DATETIME 類型視為 TIMESTAMP？啟用此選項會將 DATETIME 的預設 MySQL 資料類型對 Java 類型對應從 'java.time.LocalDateTime' 變更為 'java.sql.Timestamp'。鑑於 DATETIME 類型的性質及其無法表示瞬時值，除非驅動程式與框架或 API 一起使用，否則不建議啟用此選項，而這些框架或 API 專門期望遵循預設 MySQL 資料類型到 Java 類型對應的物件，例如 'javax.sql.rowset.CachedRowSet' 的情況。

treatUtilDateAsTimestamp

驅動程式是否應在 'PreparedStatement.setObject()' 中將 'java.util.Date' 視為 TIMESTAMP？

yearIsDateType

JDBC 驅動程式是否應將 MySQL 類型 YEAR 視為 'java.sql.Date' 或 SHORT？

zeroDateTimeBehavior

當驅動程式遇到由全零組成的 DATETIME 值時，應該如何處理？MySQL 使用全零來表示無效日期。有效的值為「EXCEPTION」、「ROUND」和「CONVERT_TO_NULL」。