Question

我发现只有one similar question但是对于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() documentation会发现以下内容：

DATEADD（datepart，number，date）
  ....
  号码   是一个可以解析为int 的表达式，该表达式被添加到日期的datepart中。用户定义的变量有效。

如果我理解正确，这意味着这种方法不能用于将unix时间戳转换为TSQL时间戳，这很好地原谅了我的语言，但只是简单的延迟。

我的问题是：

我对这种情况的解释是正确的吗？
还有其他单行在TSQL中执行此转换吗？

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

Answer 1

简单，首先添加整天，然后添加剩余的ms。一天有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

Answer 2

这应该适用于那些漫长的时代。

SELECT DATEADD(SECOND, 1359016610667 / 1000, '19700101 00:00')

将unix epoch时间戳转换为TSQL日期时间

2 个答案: