13

同様の質問を1つだけ見つけましたが、MySQLに関するものです。

私はWebサービスに取り組んでいて、データベース（MS SQLサーバー）にクエリを実行する必要がありました。正しい結果が得られなかったため、SQLクライアントを介してクエリをテストすることにしました。WebサービスはHibernateを使用してDBにアクセスし、すべての時間値は常にlong値（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

javalongがTSQLbigintと同等であることを確認しました。どちらも長いです。dateadd （）のドキュメントを読み直すと、次のことがわかりました。8 B

DATEADD（datepart、number、date）
....
number日付のdatepartに追加されるintに解決
できる式です。ユーザー定義変数は有効です。

私がこれを正しく理解している場合、これは、UNIXタイムスタンプをTSQLタイムスタンプに変換するためにこのアプローチを使用できないことを意味します。これは、私の言語を許しますが、単なる愚かです。

私の質問は次のとおりです。

  • この状況の私の解釈は正しいですか？
  • TSQLでこの変換を行うための他のワンライナーはありますか？


日付引数（）を変更するPS'1970-01-01 00:00:00.0'は、解決策として受け入れられません。私はデバッグ中ですが、ミリ秒を再計算したくありません:)

4

2 に答える 2

20

簡単です。最初に丸1日を追加し、次に残りのミリ秒を追加します。1日に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 に答える