将unix历元时间戳转换为TSQL datetime

我只找到了MySQL

我当时正在处理一个web服务，不得不查询数据库（MS SQL server）。由于无法得到正确的结果，我决定通过SQL客户机测试查询。web服务使用Hibernate访问数据库，所有时间值始终表示为长值（unix时间）。为了测试它，我需要将unix时间戳转换为TSQL时间戳。这就是我想到的：

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

哪些产出：

1970-01-01 00:00:00.123

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

1359016610667

但是，我的实际数据要大一点

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

哪些产出：

1970-01-01 00:00:00.123

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

1359016610667

所以，我试着：

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

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

select CAST (1359016610667 AS BIGINT) 

哪些产出：

1970-01-01 00:00:00.123

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

1359016610667

我确保这相当于-它们都

8b

长。重读该报告揭示了以下几点：

DATEADD（日期部分、编号、日期）
..
数字
是一个表达式，可以解析为添加到日期部分的int。用户定义的变量是有效的

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

我的问题是：

• 我对这种情况的解释正确吗
• 在TSQL中是否有任何其他的一个liner来执行此转换

PS

---

修改日期参数（

'1970-01-01 00:00:00.0'

）作为解决方案是不可接受的。我正在调试，我不想重新计算毫秒：）

简单，先加上整天，然后再加上剩下的毫秒。一天有86400000毫秒

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

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

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

---

被否决的选民能解释一下为什么这个问题被否决吗？哈哈，又一次？好的，请看上面的注释……这种只添加秒而不是毫秒和天的方法（如@ben的答案）在处理诸如“2099年12月31日”之类的日期时会导致算术溢出错误，SQL试图将秒数转换为整数。结果是2013-01-24 08:36:50.667，但在哪个时区？UTC？@luisdev如果输入的unix时间戳是UTC，则结果将是UTC。如果不是，那就不是。