Я нашел толькоодин похожий вопрос но для MySQL.

Я работал над веб-сервисом и должен был запросить базу данных (сервер MS SQL). Так как я не мог получить правильный результат, я решил проверить запрос через клиент SQL. Веб-сервис использует 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

Я убедился, чтоЯва Лонг эквивалентноTSQL bigint - они оба8 B долго. Перечитываядокументация dateadd () выявлено следующее:

DATEADD (datepart, число, дата)
....
номер
Это выражение, которое может бытьразрешено в Int это добавляется к части даты date. Пользовательские переменные действительны.

Если я правильно понимаю, это означает, что этот подход не может быть использован для преобразования метки времени Unix в метку времени TSQL, что, простите мой язык, но просто запаздывает.

Мои вопросы:

правильна ли моя интерпретация этой ситуации?есть ли другойодин лайнер сделать это преобразование в TSQL?

PS
изменение аргумента даты ('1970-01-01 00:00:00.0') не является приемлемым решением. Я отлаживаю и не хочу пересчитывать миллисекунды :)