13

除了 MySQL，我只发现了一个类似的问题。

我正在开发 Web 服务，并且必须查询数据库（MS SQL 服务器）。由于我无法得到正确的结果，我决定通过 SQL 客户端测试查询。Web 服务使用 Hibernate 访问数据库，所有时间值始终表示为长值（unix 纪元时间）。为了测试它，我需要将 unix 时间戳转换为 TSQL 时间戳。这就是我想出的：

select dateadd(ms,123,'1970-01-01 00:00:00.0');

输出：

1970-01-01 00:00:00.123

但是，我的实际数据有点大

select dateadd(ms,1359016610667 ,'1970-01-01 00:00:00.0');

输出：

Error code 0, SQL state 22001: Data truncation
Error code 8115, SQL state 22003: Arithmetic overflow error converting expression to data type int.

所以，我尝试了：

select dateadd(ms,CAST (1359016610667 AS BIGINT) ,'1970-01-01 00:00:00.0');

输出完全相同的错误。为了安全起见，我尝试了：

select CAST (1359016610667 AS BIGINT)

输出：

1359016610667

我确保java long等同于TSQL bigint - 它们都很8 B长。重读dateadd() 文档发现以下内容：

DATEADD (datepart , number , date )
....
number
是一个表达式，可以解析为添加到 date 的 datepart 的 int。用户定义的变量是有效的。

如果我理解正确，这意味着这种方法不能用于将 unix 时间戳转换为 TSQL 时间戳，这是，好吧，请原谅我的语言，但只是愚蠢的。

我的问题是：

  • 我对这种情况的解释正确吗？
  • 在 TSQL 中是否有任何其他单线来进行这种转换？

PS
修改日期参数 ( '1970-01-01 00:00:00.0') 是不可接受的解决方案。我正在调试，我不想重新计算毫秒数:)

4

2 回答 2

20

很简单，首先添加整天，然后添加剩余的毫秒。一天有 86,400,000 毫秒。

declare @unixTS bigint
set @unixTS = 1359016610667


select dateadd(ms, @unixTS%(3600*24*1000), 
    dateadd(day, @unixTS/(3600*24*1000), '1970-01-01 00:00:00.0')
)

结果是2013-01-24 08:36:50.667

于 2013-01-24T20:41:02.467 回答
11

这对于那些漫长的时代应该是完美的。

SELECT DATEADD(SECOND, 1359016610667 / 1000, '19700101 00:00')
于 2016-06-29T19:18:07.037 回答