当服务器时区不是 UTC 时，从 Java 中的 MySQL 检索 UTC DATETIME 字段
Retrieving UTC DATETIME field from MySQL in Java when server timezone is not UTC
我正在尝试编写代码以使用 Java 和 MySQL 与第三方开发的数据库进行互操作。该数据库有一个字段，将时间戳存储在 DATETIME 字段中作为 UTC 日期。数据库和客户端 运行 所在的服务器的时区设置为非 UTC 时区 (Europe/London)，因此默认情况下时间戳被错误地读回，就好像它是本地时间一样。我正在尝试编写代码以将其读回为 UTC。
我在这里阅读了几个类似的问题，但其中 none 个答案对我有用：
- MySQL - how to store time with correct timezone? (from Java)
- How to store a java.util.Date into a MySQL timestamp field in the UTC/GMT timezone?
- Date in UTC in mysql
- How do I set the time zone of MySQL?
不幸的是，我无法更改任何服务器设置，因此我尝试使用连接的 "time_zone" 变量将数据库服务器设置为使用 UTC，并将可选的 Calendar 参数设置为 ResultSet.getTimestamp检索日期，但这对结果没有影响。这是我的代码：
private static final Calendar UTCCALENDAR = Calendar.getInstance (TimeZone.getTimeZone (ZoneOffset.UTC));
public Date getDate ()
{
try (Connection c = dataSource.getConnection ();
PreparedStatement s = c
.prepareStatement ("select datefield from dbmail_datefield where physmessage_id=?"))
{
fixTimeZone (c);
s.setLong (1, getPhysId ());
try (ResultSet rs = s.executeQuery ())
{
if (!rs.next ()) return null;
return new Date (rs.getTimestamp(1,UTCCALENDAR).getTime ()); // do not use SQL timestamp object, as it fucks up comparisons!
}
}
catch (SQLException e)
{
throw new MailAccessException ("Error accessing dbmail database", e);
}
}
private void fixTimeZone (Connection c)
{
try (Statement s = c.createStatement ())
{
s.executeUpdate ("set time_zone='+00:00'");
}
catch (SQLException e)
{
throw new MailAccessException ("Unable to set SQL connection time zone to UTC", e);
}
}
我尝试读取的数据库字段中存储了一个值，如下所示：
mysql> select * from dbmail_datefield where physmessage_id=494539;
+----------------+--------+---------------------+
| physmessage_id | id | datefield |
+----------------+--------+---------------------+
| 494539 | 494520 | 2015-04-16 10:30:30 |
+----------------+--------+---------------------+
但不幸的是，结果是 BST 而不是 UTC：
java.lang.AssertionError: expected:<Thu Apr 16 11:30:30 BST 2015> but was:<Thu Apr 16 10:30:30 BST 2015>
也许你可以像下面这样使用JodaTime；
private static final Calendar UTCCALENDAR = Calendar.getInstance (TimeZone.getTimeZone (ZoneOffset .UTC));
public Date getDate ()
{
try (Connection c = dataSource.getConnection ();
PreparedStatement s = c
.prepareStatement ("select datefield from dbmail_datefield where physmessage_id=?"))
{
s.setLong (1, getPhysId ());
try (ResultSet rs = s.executeQuery ())
{
if (!rs.next ()) return null;
DateTime dt = new LocalDateTime(rs.getTimestamp(1,UTCCALENDAR).getTime ()).toDateTime(DateTimeZone.forID("Europe/London"));
return dt.toDate(); }
}
catch (SQLException e)
{
throw new MailAccessException ("Error accessing dbmail database", e);
}
}
编辑：
java.util.Date 与时区无关。 toDateTime 方法负责处理 TimeZone 和 DST，因此您无需关心它
以下代码：
public static void main(String[] args) {
// 29/March/2015 1:05 UTC
DateTime now = new DateTime(2015, 3,29,1,5,DateTimeZone.UTC);
// Pre DST 29/March/2015 0:30 UTC
DateTime preDst = new DateTime(2015, 3,29,0,30,DateTimeZone.UTC);
System.out.println("1:05 UTC:"+now);
System.out.println("0:30 UTC:"+preDst);
DateTimeZone europeDTZ = DateTimeZone.forID("Europe/London");
DateTime europeLondon = now.toDateTime(europeDTZ);
System.out.println("1:05 UTC as Europe/London:"+europeLondon);
DateTime europeLondonPreDst = preDst.toDateTime(europeDTZ);
System.out.println("0:30 UTC as Europe/London:"+europeLondonPreDst);
}
将打印：
1:05 UTC:2015-03-29T01:05:00.000Z
0:30 UTC:2015-03-29T00:30:00.000Z
1:05 UTC as Europe/London:2015-03-29T02:05:00.000+01:00
0:30 UTC as Europe/London:2015-03-29T00:30:00.000Z
如果您可以看到 JodaTime 负责 DST。
不要考虑转换或调整时区。不要考虑 mysql 用来存储时间戳的 TZ 或类似的东西。那些事情已经处理好了。
您必须处理三件事：输入、输出和错误。
输入
当用户在没有明确时区的情况下输入日期（在表单中）时，您必须知道他打算使用什么 TZ。您可以使用设置了时区的 SimpleDateFormat 对象来解决此问题。您不必转换输入日期，您必须 'interpret' 正确。正确解释日期或时间戳后，您就完成了输入。
输入不仅是用户输入，还包括配置文件。
输出
这里也一样。忘掉 TZ 有什么你的日期对象和时间戳有 none，它们只是从纪元开始的毫秒数。您必须将您的日期格式化为用户期望的 TZ，以便他理解它们。
错误
您的代码中可能存在与 TZ 相关的错误，但图书馆也可能存在错误！！
我注意到 mysql java 驱动程序无法将客户端时区传递给服务器。
此命令 s.executeUpdate ("set time_zone='+xx:yy'"); 是解决方法，但您使用错误。在插入和查询之前，您必须用它告诉服务器客户端正在使用的 TZ。变量存储在会话中。也许你可以在你的连接池配置上自动化它。
这是必需的，以便服务器知道客户端需要使用什么 TZ 来读取或写入。 这不依赖于服务器 TZ。它并不意味着 "store this date in UTC"，而是意味着 "this date I am giving to you is UTC" 和 "Send me result sets in UTC"。无论您使用 Date class 及其内部 TZ，驱动程序都搞砸了，您需要设置该会话变量。
默认情况下，它假定客户端 TZ 与服务器 TZ 相同，因此您不必担心，因为您说它们是相同的。
如果您想使用时区，您可以将列读取为 UTC。
ZonedDateTime zdt = ZonedDateTime.of(rs.getTimestamp(1).toLocalDateTime(), ZoneOffset.UTC);
接下来您可以更改为您想要使用的任何时区：
zdt = zdt.withZoneSameInstant(ZoneId.of(
TARGET_ZONE));
如果您只想读取日期而不关心区域，请只使用：
LocalDateTime ldt = rs.getTimestamp(1).toLocalDateTime()
您将获得不带时区的 LocalDateTime。
如果必须 return java.util.Date 使用：
Date.from(ldt.atZone(ZoneOffset.UTC).toInstant());
在我看来，你最好的选择是告诉 MySQL 使用 GMT 并在你的应用程序代码中处理所有本地时间问题，而不是你的数据库。数据库中的值始终是 GMT，句点，这是明确的。正如您所说，通过夏令时（夏令时）调整，您最终可以在数据库中得到相同的值，对于我们人类来说，这是两个不同的时间。
这也使数据库具有可移植性。如果您搬到北美并开始使用 MySQL 设置为（比如说）中部时间，突然间您数据库中的值似乎已经移动了几个小时。当我从 U.S 的东海岸移动它时，我继承了一个使用服务器本地时间的数据库时遇到了这个问题。到西海岸，没有想过检查 MySQL 是否从属于机器的区域...
long t = 1351382400000; // the timestamp in UTC
String insert = "INSERT INTO my_table (timestamp) VALUES (?)";
PreparedStatement stmt = db.prepareStatement(insert);
java.sql.Timestamp date = new Timestamp(t);
stmt.setTimestamp(1, date);
stmt.executeUpdate();
.....
TimeZone timezone = TimeZone.getTimeZone("MyTimeZoneId");
Calendar cal = java.util.Calendar.getInstance(timezone);
String select = "SELECT timestamp FROM my_table";
// some code omitted....
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
java.sql.Timestamp ts = rs.getTimestamp(1);
cal.setTimeInMillis(ts.getTime());
System.out.println("date in db: " + cal.getTime());
}
您的客户端 getDate() 代码就目前而言看起来是正确的。我认为您还需要让 MySQL Connector/J JDBC 驱动程序将存储在 table 中的日期 视为 UTC 日期，以避免虚假的时区转换。这意味着设置有效的服务器时区，以及用于 JDBC getTimestamp 调用的客户端会话时区和日历。
看看你在失败的断言中得到的值，以及错误的方向：
expected:<Thu Apr 16 11:30:30 BST 2015> but was:<Thu Apr 16 10:30:30 BST 2015>
您返回的是 10:30 BST，即 9:30 GMT。这与数据库将 table 中的 10:30 视为 BST 值并在您将其解析为 GMT 日期之前为您虚假地将其转换为 GMT 一致。这与 GMT 值被虚假地转换为 BST 的方向相反。
这可能是 JDBC 特有的问题，因为 JDBC 要求将时间转换为本地时区。 （MySQL C API 没有，可能是因为 C 的经典时间类型不像 Java 那样具有区域意识。）它需要知道它正在转换哪个区域来自，还有。 MySQL TIMESTAMP 类型始终存储为 UTC。但这并没有针对 DATETIME 类型说明。我 认为 这意味着 MySQL 将把 DATETIME 列值解释为服务器的时区。您提到的设置为 BST，这与您的断言错误消息中显示的偏移方向一致。
您设置的 time_zone 会话变量告诉 MySQL 服务器您的客户端计算机的时区是什么，但它不会影响服务器认为自己的时区是什么。这可以用 serverTimezone JDBC connection property 覆盖。在您的连接上，将 serverTimezone 设置为 UTC，并确保 useLegacyDatetimeCode 已关闭。 （如果不起作用，请查看其他与区域相关的属性。）看看是否可以让您的日期以 UTC 的形式显示，并具有与数据库中相同的日历字段值。
请注意，这将改变您数据库中其他 DATETIME 值的解释：它们现在看起来都像 UTC 日期（在您的 JDBC 连接的上下文中).这是否正确将取决于它们最初是如何填充的。虽然您的客户端代码将具有您想要的行为，但我不知道如果不在服务器级别将服务器的时区设置为 UTC，是否可以使整个系统的行为完全一致。基本上，如果它没有将其区域设置为 UTC，则它没有完全配置为您想要的行为，您正在绕过它。
我正在尝试编写代码以使用 Java 和 MySQL 与第三方开发的数据库进行互操作。该数据库有一个字段，将时间戳存储在 DATETIME 字段中作为 UTC 日期。数据库和客户端 运行 所在的服务器的时区设置为非 UTC 时区 (Europe/London)，因此默认情况下时间戳被错误地读回，就好像它是本地时间一样。我正在尝试编写代码以将其读回为 UTC。
我在这里阅读了几个类似的问题，但其中 none 个答案对我有用：
- MySQL - how to store time with correct timezone? (from Java)
- How to store a java.util.Date into a MySQL timestamp field in the UTC/GMT timezone?
- Date in UTC in mysql
- How do I set the time zone of MySQL?
不幸的是，我无法更改任何服务器设置，因此我尝试使用连接的 "time_zone" 变量将数据库服务器设置为使用 UTC，并将可选的 Calendar 参数设置为 ResultSet.getTimestamp检索日期，但这对结果没有影响。这是我的代码：
private static final Calendar UTCCALENDAR = Calendar.getInstance (TimeZone.getTimeZone (ZoneOffset.UTC));
public Date getDate ()
{
try (Connection c = dataSource.getConnection ();
PreparedStatement s = c
.prepareStatement ("select datefield from dbmail_datefield where physmessage_id=?"))
{
fixTimeZone (c);
s.setLong (1, getPhysId ());
try (ResultSet rs = s.executeQuery ())
{
if (!rs.next ()) return null;
return new Date (rs.getTimestamp(1,UTCCALENDAR).getTime ()); // do not use SQL timestamp object, as it fucks up comparisons!
}
}
catch (SQLException e)
{
throw new MailAccessException ("Error accessing dbmail database", e);
}
}
private void fixTimeZone (Connection c)
{
try (Statement s = c.createStatement ())
{
s.executeUpdate ("set time_zone='+00:00'");
}
catch (SQLException e)
{
throw new MailAccessException ("Unable to set SQL connection time zone to UTC", e);
}
}
我尝试读取的数据库字段中存储了一个值，如下所示：
mysql> select * from dbmail_datefield where physmessage_id=494539;
+----------------+--------+---------------------+
| physmessage_id | id | datefield |
+----------------+--------+---------------------+
| 494539 | 494520 | 2015-04-16 10:30:30 |
+----------------+--------+---------------------+
但不幸的是，结果是 BST 而不是 UTC：
java.lang.AssertionError: expected:<Thu Apr 16 11:30:30 BST 2015> but was:<Thu Apr 16 10:30:30 BST 2015>
也许你可以像下面这样使用JodaTime；
private static final Calendar UTCCALENDAR = Calendar.getInstance (TimeZone.getTimeZone (ZoneOffset .UTC));
public Date getDate ()
{
try (Connection c = dataSource.getConnection ();
PreparedStatement s = c
.prepareStatement ("select datefield from dbmail_datefield where physmessage_id=?"))
{
s.setLong (1, getPhysId ());
try (ResultSet rs = s.executeQuery ())
{
if (!rs.next ()) return null;
DateTime dt = new LocalDateTime(rs.getTimestamp(1,UTCCALENDAR).getTime ()).toDateTime(DateTimeZone.forID("Europe/London"));
return dt.toDate(); }
}
catch (SQLException e)
{
throw new MailAccessException ("Error accessing dbmail database", e);
}
}
编辑：
java.util.Date 与时区无关。 toDateTime 方法负责处理 TimeZone 和 DST，因此您无需关心它
以下代码：
public static void main(String[] args) {
// 29/March/2015 1:05 UTC
DateTime now = new DateTime(2015, 3,29,1,5,DateTimeZone.UTC);
// Pre DST 29/March/2015 0:30 UTC
DateTime preDst = new DateTime(2015, 3,29,0,30,DateTimeZone.UTC);
System.out.println("1:05 UTC:"+now);
System.out.println("0:30 UTC:"+preDst);
DateTimeZone europeDTZ = DateTimeZone.forID("Europe/London");
DateTime europeLondon = now.toDateTime(europeDTZ);
System.out.println("1:05 UTC as Europe/London:"+europeLondon);
DateTime europeLondonPreDst = preDst.toDateTime(europeDTZ);
System.out.println("0:30 UTC as Europe/London:"+europeLondonPreDst);
}
将打印：
1:05 UTC:2015-03-29T01:05:00.000Z
0:30 UTC:2015-03-29T00:30:00.000Z
1:05 UTC as Europe/London:2015-03-29T02:05:00.000+01:00
0:30 UTC as Europe/London:2015-03-29T00:30:00.000Z
如果您可以看到 JodaTime 负责 DST。
不要考虑转换或调整时区。不要考虑 mysql 用来存储时间戳的 TZ 或类似的东西。那些事情已经处理好了。 您必须处理三件事：输入、输出和错误。
输入
当用户在没有明确时区的情况下输入日期（在表单中）时，您必须知道他打算使用什么 TZ。您可以使用设置了时区的 SimpleDateFormat 对象来解决此问题。您不必转换输入日期，您必须 'interpret' 正确。正确解释日期或时间戳后，您就完成了输入。
输入不仅是用户输入，还包括配置文件。
输出
这里也一样。忘掉 TZ 有什么你的日期对象和时间戳有 none，它们只是从纪元开始的毫秒数。您必须将您的日期格式化为用户期望的 TZ，以便他理解它们。
错误
您的代码中可能存在与 TZ 相关的错误，但图书馆也可能存在错误！！
我注意到 mysql java 驱动程序无法将客户端时区传递给服务器。
此命令 s.executeUpdate ("set time_zone='+xx:yy'"); 是解决方法，但您使用错误。在插入和查询之前，您必须用它告诉服务器客户端正在使用的 TZ。变量存储在会话中。也许你可以在你的连接池配置上自动化它。
这是必需的，以便服务器知道客户端需要使用什么 TZ 来读取或写入。 这不依赖于服务器 TZ。它并不意味着 "store this date in UTC"，而是意味着 "this date I am giving to you is UTC" 和 "Send me result sets in UTC"。无论您使用 Date class 及其内部 TZ，驱动程序都搞砸了，您需要设置该会话变量。
默认情况下，它假定客户端 TZ 与服务器 TZ 相同，因此您不必担心，因为您说它们是相同的。
如果您想使用时区，您可以将列读取为 UTC。
ZonedDateTime zdt = ZonedDateTime.of(rs.getTimestamp(1).toLocalDateTime(), ZoneOffset.UTC);
接下来您可以更改为您想要使用的任何时区：
zdt = zdt.withZoneSameInstant(ZoneId.of(
TARGET_ZONE));
如果您只想读取日期而不关心区域，请只使用：
LocalDateTime ldt = rs.getTimestamp(1).toLocalDateTime()
您将获得不带时区的 LocalDateTime。
如果必须 return java.util.Date 使用：
Date.from(ldt.atZone(ZoneOffset.UTC).toInstant());
在我看来，你最好的选择是告诉 MySQL 使用 GMT 并在你的应用程序代码中处理所有本地时间问题，而不是你的数据库。数据库中的值始终是 GMT，句点，这是明确的。正如您所说，通过夏令时（夏令时）调整，您最终可以在数据库中得到相同的值，对于我们人类来说，这是两个不同的时间。
这也使数据库具有可移植性。如果您搬到北美并开始使用 MySQL 设置为（比如说）中部时间，突然间您数据库中的值似乎已经移动了几个小时。当我从 U.S 的东海岸移动它时，我继承了一个使用服务器本地时间的数据库时遇到了这个问题。到西海岸，没有想过检查 MySQL 是否从属于机器的区域...
long t = 1351382400000; // the timestamp in UTC
String insert = "INSERT INTO my_table (timestamp) VALUES (?)";
PreparedStatement stmt = db.prepareStatement(insert);
java.sql.Timestamp date = new Timestamp(t);
stmt.setTimestamp(1, date);
stmt.executeUpdate();
.....
TimeZone timezone = TimeZone.getTimeZone("MyTimeZoneId");
Calendar cal = java.util.Calendar.getInstance(timezone);
String select = "SELECT timestamp FROM my_table";
// some code omitted....
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
java.sql.Timestamp ts = rs.getTimestamp(1);
cal.setTimeInMillis(ts.getTime());
System.out.println("date in db: " + cal.getTime());
}
您的客户端 getDate() 代码就目前而言看起来是正确的。我认为您还需要让 MySQL Connector/J JDBC 驱动程序将存储在 table 中的日期 视为 UTC 日期，以避免虚假的时区转换。这意味着设置有效的服务器时区，以及用于 JDBC getTimestamp 调用的客户端会话时区和日历。
看看你在失败的断言中得到的值，以及错误的方向：
expected:<Thu Apr 16 11:30:30 BST 2015> but was:<Thu Apr 16 10:30:30 BST 2015>
您返回的是 10:30 BST，即 9:30 GMT。这与数据库将 table 中的 10:30 视为 BST 值并在您将其解析为 GMT 日期之前为您虚假地将其转换为 GMT 一致。这与 GMT 值被虚假地转换为 BST 的方向相反。
这可能是 JDBC 特有的问题，因为 JDBC 要求将时间转换为本地时区。 （MySQL C API 没有，可能是因为 C 的经典时间类型不像 Java 那样具有区域意识。）它需要知道它正在转换哪个区域来自，还有。 MySQL TIMESTAMP 类型始终存储为 UTC。但这并没有针对 DATETIME 类型说明。我 认为 这意味着 MySQL 将把 DATETIME 列值解释为服务器的时区。您提到的设置为 BST，这与您的断言错误消息中显示的偏移方向一致。
您设置的 time_zone 会话变量告诉 MySQL 服务器您的客户端计算机的时区是什么，但它不会影响服务器认为自己的时区是什么。这可以用 serverTimezone JDBC connection property 覆盖。在您的连接上，将 serverTimezone 设置为 UTC，并确保 useLegacyDatetimeCode 已关闭。 （如果不起作用，请查看其他与区域相关的属性。）看看是否可以让您的日期以 UTC 的形式显示，并具有与数据库中相同的日历字段值。
请注意，这将改变您数据库中其他 DATETIME 值的解释：它们现在看起来都像 UTC 日期（在您的 JDBC 连接的上下文中).这是否正确将取决于它们最初是如何填充的。虽然您的客户端代码将具有您想要的行为，但我不知道如果不在服务器级别将服务器的时区设置为 UTC，是否可以使整个系统的行为完全一致。基本上，如果它没有将其区域设置为 UTC，则它没有完全配置为您想要的行为，您正在绕过它。