在日期时间字段或时区问题疯狂的MS SQL Server JDBC驱动程序?

时间:2015-04-16 20:09:21

标签: java sql-server datetime jdbc

在调试过程中,我以简单的例子结束:

select convert(datetime, '2015-04-15 03:30:00') as ts
go

Apr 15 2015 03:30AM
(1 row affected)

select convert(int, datediff(second, '1970-01-01 00:00:00',
                    convert(datetime, '2015-04-15 03:30:00'))) as ts
go

1429068600
(1 row affected)

$ TZ=UTC date --date=@1429068600 +%F_%T
2015-04-15_03:30:00

当我从JDBC执行查询时,我得到2个不等于上面的结果!!!!代码:

String TEST_QUERY = "select convert(datetime, '2015-04-15 03:30:00') as ts";
PreparedStatement stmt2 = conn.prepareStatement(TEST_QUERY);
ResultSet rs = stmt2.executeQuery();
rs.next();
logger.info("getTimestamp().getTime(): {}", rs.getTimestamp("ts").getTime());
logger.info("getDate().getTime(): {}", rs.getDate("ts").getTime());
stmt2.close();

执行结果(我使用Coreutils date实用程序仔细检查结果):

=> getTimestamp().getTime(): 1429057800000

$ TZ=UTC date --date=@1429057800 +%F_%T
2015-04-15_00:30:00

=> getDate().getTime(): 1429045200000

$ TZ=UTC date --date=@1429045200 +%F_%T
2015-04-14_21:00:00

Official docs for date types and JDBC Java mapping对结果差异一无所知......

我的程序在GMT+03:00时区执行,我有SQL Server 2008并尝试使用https://msdn.microsoft.com/en-us/sqlserver/aa937724.aspx中的JDBC驱动程序4.0和4.1

我期望在所有情况下获得UTC时间戳(从1970年开始),这仅适用于我用于交互式调试查询的Linux ODBC tsql实用程序。

WTF?

3 个答案:

答案 0 :(得分:3)

您的第一对查询计算自纪元(本地)日期当地午夜起的秒数。这种差异在任何时区都是相同的,因此当您将数据库时区设置为UTC并将先前确定的偏移量转换回时间戳时,您会获得与数字匹配的“相同”日期和时间,但它们代表不同的绝对时间,因为它们是相对于不同的TZ。

当您通过JDBC执行查询时,您正在数据库时区GMT + 03:00计算Timestampjava.sql.Timestamp代表绝对时间,但表示为在时代转折时距午夜 GMT 的偏移量。 JDBC驱动程序知道如何补偿。因此,您记录的是1970-01-01 00:00:00 GMT+00:002015-04-15 03:30:00 GMT+03:00之间的时差。

getDate().getTime()版本不太明确,但是当您将时间戳检索为Date,从而截断时间部分时,相对于数据库时间执行截断区。之后,与其他情况类似,java.sql.Date.getTime()返回从纪元转向到结果绝对时间的偏移量。也就是说,它正在计算1970-01-01 00:00:00 GMT+00:002015-04-15 00:00:00 GMT+03:00

之间的差异

这一切都是一致的。

答案 1 :(得分:2)

JD-GUI的帮助下,我调查了SQL Server JDBC二进制文件。

rs.getTimestamp()方法导致:

package com.microsoft.sqlserver.jdbc;
final class DDC {

static final Object convertTemporalToObject(
       JDBCType paramJDBCType, SSType paramSSType, Calendar paramCalendar, int paramInt1, long paramLong, int paramInt2) {
    TimeZone localTimeZone1 = null != paramCalendar ? 
         paramCalendar.getTimeZone() : TimeZone.getDefault();
    TimeZone localTimeZone2 = SSType.DATETIMEOFFSET == paramSSType ? 
         UTC.timeZone : localTimeZone1;

    Object localObject1 = new GregorianCalendar(localTimeZone2, Locale.US);

    ...

     ((GregorianCalendar)localObject1).set(1900, 0, 1 + paramInt1, 0, 0, 0);
        ((GregorianCalendar)localObject1).set(14, (int)paramLong);

从TDS协议的结果集读者调用:

package com.microsoft.sqlserver.jdbc;

final class TDSReader {

final Object readDateTime(int paramInt, Calendar paramCalendar, JDBCType paramJDBCType, StreamType paramStreamType)
  throws SQLServerException
{
  ...
  switch (paramInt)
  {
  case 8:
    i = readInt();
    j = readInt();

    k = (j * 10 + 1) / 3;
    break;
  ...
  return DDC.convertTemporalToObject(paramJDBCType, SSType.DATETIME, paramCalendar, i, k, 0);
}

因此,datetime的两个4字节字代表1900年的天数和白天的毫秒数,并且数据设置为Calendar

很难检查Calendar的来源。但是代码显示正在使用本地Java TZ(查看TimeZone.getDefault())。

如果总结该信息,则可以认为JDBC驱动程序是纯编写的。如果认为数据库在UTC中保留1900年的时间,则需要应用TZ校正从Java端的UTC驱动程序获取long getTimestamp().getTime()结果,因为驱动程序假定他从数据库获得本地时间。

重要更新我尝试在应用程序的最开始时将默认语言环境设置为UTC:

TimeZone.setDefault(TimeZone.getTimeZone("GMT+00:00"));

getTimestamp().getTime()获取UTC ms。那是胜利!从1970年开始,我可以避免使用骇人听闻的SQL Server日期算法。

答案 2 :(得分:1)

如其他答案所述,JDBC驱动程序将调整JVM默认TimeZone的日期/时间。当数据库和应用程序在不同的时区运行时,这当然只是一个问题。

如果您需要不同时区的日期/时间,您可以更改JVM的默认时区(如另一个答案所示),但如果您的代码在应用程序服务器中运行,则可能无法实现托管多个应用程序。

更好的选择可能是使用重载方法获取Calendar对象来明确指定所需的时区。

Connection conn = ...;
String sql = ...;
Timestamp tsParam = ...;

// Get Calendar for UTC timezone
Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("UTC"));

try (PreparedStatement stmt = conn.prepareStatement(sql)) {

    // Send statement parameter in UTC timezone
    stmt.setTimestamp(1, tsParam, cal);

    try (ResultSet rs = stmt.executeQuery()) {
        while (rs.next()) {

            // Get result column in UTC timezone
            Timestamp tsCol = rs.getTimestamp("...", cal);

            // Use tsCol here
        }
    }
}