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”。

请注意，在与 "forceConnectionTimeZoneToSession=false" 和 "preserveInstants=false" 结合使用的情况下，将值设置为 'connectionTimeZone' 不会产生任何影响，因为在这种情况下，此选项既不用于更改会话时区，也不用于时间基数据的时间区转换。

以前的连接选项 'serverTimezone' 仍然有效，作为此选项的别名，但在将来可能会被弃用。

有关更多详细信息，请参阅 'forceConnectionTimeZoneToSession' 和 'preserveInstants'。

forceConnectionTimeZoneToSession

如果启用，将由 'connectionTimeZone' 连接属性确定的时区值设置为当前服务器会话 'time_zone' 变量。如果时区值作为地理时区给出，则 Connector/J 会按原样将此值设置为服务器会话，在这种情况下，必须预先填充时区系统表（有关更多详细信息，请参阅 MySQL Server 文档）；但是，如果该值作为格林尼治/UTC 的偏移量给出，使用任何受支持的语法，则服务器会话时区将设置为从 UTC 的数字偏移量。

这样，在将瞬时 Java 对象（如 'java.sql.Timestamp' 或 'java.time.OffsetDateTime'）存储在 TIMESTAMP 列中时，无需在 JVM 默认时区和连接时区之间进行中间转换，即可存储正确的瞬时毫秒值。

请注意，这也影响 MySQL 函数（如 'NOW()'、'CURTIME()' 或 'CURDATE()'）的结果。

如果与 "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

驱动程序是否应将 MySQL DATETIME 类型视为 'ResultSet.getObject()' 中的 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"。