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

发布时间：2020-12-16 01:52:36 所属栏目：安全来源：网络整理

导读：我发现只有 one similar question但是对于MySQL. 我正在开发一个Web服务,不得不查询数据库(MS SQL服务器).由于我无法得到正确的结果,我决定通过SQL客户端测试查询. Web服务使用Hibernate访问数据库,所有时间值始终表示为长值(unix纪元时间).为了测试它,我需

我发现只有 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 )
….
number
Is an expression that can be resolved to an int that is added to a datepart of date. User-defined variables are valid.

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

我的问题是：

>我对这种情况的解释是否正确？
>在TSQL中有没有其他单行代码进行此转换？

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

解决方法

容易,首先添加整天,然后添加剩余的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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!