SQLServerにはMySQLのUNIX_TIMESTAMP()に相当するものがないことに気付いたかもしれません。 機能。
ただし、SQLServerでUnixタイムスタンプを返すことはそれほど難しくありません。
Unixタイムスタンプ（Unixエポック時間、Unix時間、またはPOSIX時間とも呼ばれます）は、1970年1月1日木曜日の00:00:00、Coordinated Universal Time（UTC）から経過した秒数です。したがって、SQL Serverでは、いくつかのT-SQL関数を使用してこれを返すことができます。
SQLServerUnixタイムスタンプ
SQLServerでUnixタイムスタンプを返す方法は次のとおりです。
SELECT DATEDIFF(SECOND,'1970-01-01', GETUTCDATE()) AS 'SQL Server Result';
結果：
+---------------------+ | SQL Server Result | |---------------------| | 1560833178 | +---------------------+
したがって、DATEDIFF()を使用できます 1970-01-01と現在の差を秒単位で返す関数。 GETUTCDATE()を使用します 現在の日付と時刻をUTC時間で返す関数。
このコードは2038年まで機能します（正確には「2038-01-1903：14：07」）。その後のUnixタイムスタンプの場合は、コードを少し変更する必要があります。その日付を過ぎたUnixタイムスタンプが必要な場合は、読み進めてください。
MySQLUnixタイムスタンプと同等
比較のために、MySQLのUNIX_TIMESTAMP()を実行した場合 まったく同時に、私はこれを取得します：
SELECT UNIX_TIMESTAMP() AS 'MySQL Result';
結果：
+--------------+ | MySQL Result | +--------------+ | 1560833178 | +--------------+
同じ結果。 MySQLは結果を符号なし整数として返します。ただし、（オプションの）date引数が渡された場合、TIMESTAMPと同じ範囲をサポートします。 データ型。
ミリ秒を返す
より高い精度でUnixタイムスタンプを返す必要がある場合、たとえば、ミリ秒 ‘1970-01-01 00：00：00.000’ UTC以降、DATEDIFF()を交換する必要があります DATEDIFF_BIG()の関数 。
これは、DATEDIFF() intを返します 、1970年以降のミリ秒数を処理するには小さすぎます。DATEDIFF_BIG() 一方、関数は、署名された bigintを返します 、これはミリ秒を処理するのに十分すぎるほどです。
SELECT DATEDIFF_BIG(MILLISECOND,'1970-01-01 00:00:00.000', SYSUTCDATETIME()) Milliseconds;
結果：
+----------------+ | Milliseconds | |----------------| | 1560835305461 | +----------------+
ナノ秒を返す
別の例を次に示します。今回は、「1970-01-01 00：00：00.0000000」UTCからナノ秒まで続きます。
SELECT DATEDIFF_BIG(NANOSECOND,'1970-01-01 00:00:00.0000000', SYSUTCDATETIME()) Nanoseconds;
結果：
+---------------------+ | Nanoseconds | |---------------------| | 1560835321500279300 | +---------------------+
2038年問題
ミリ秒、マイクロ秒、ナノ秒を返すことはすべて問題ありませんが、厳密に言えば、これは本当のUnixエポック時間ではありません。 Unixエポック時間は秒の数です 「1970-01-0100:00:00」以降。
ただし、DATEDIFF_BIG() 厳密なUnixエポック時間を返す場合でも便利です。特に、データベースが2038年問題を克服するのに役立つ可能性があります。この場合、「2038-01-19 03:14:07」以降は、 bigintとして返される必要があります。 （8バイト整数）。これは、 intには秒数が大きすぎるためです。 データ型（4バイト整数）。 int bigint に対して、データ型は最大2,147,483,647になります。 最大9,223,372,036,854,775,807になります。
したがって、「2038-01-19 03:14:07」を過ぎたUnixタイムスタンプを返すには、DATEDIFF_BIG()を使用します。 DATEDIFF()の代わりに関数 。
これを示すために、DATEDIFF()の使用例を次に示します。 正確にその日時にUnix時間を返すには：
SELECT DATEDIFF(SECOND,'1970-01-01', '2038-01-19 03:14:07') AS 'Unix Epoch time';
結果：
+-------------------+ | Unix Epoch time | |-------------------| | 2147483647 | +-------------------+
ここまでは順調ですね。この結果はintの範囲内です -2,147,483,648から2,147,483,647の範囲（ただし上限です）なので、正しい結果が返されます。
ただし、1秒増やすと次のようになります。
SELECT DATEDIFF(SECOND,'1970-01-01', '2038-01-19 03:14:08') AS 'Unix Epoch time';
結果：
The datediff function resulted in an overflow. The number of dateparts separating two date/time instances is too large. Try to use datediff with a less precise datepart.
戻り値がintの外にあるため、エラーが発生します 範囲。
前述のように、必要なのはDATEDIFF()を交換することだけです。 DATEDIFF_BIG()の場合 ：
SELECT DATEDIFF_BIG(SECOND,'1970-01-01', '2038-01-19 03:14:08') AS 'Unix Epoch time';
結果：
+-------------------+ | Unix Epoch time | |-------------------| | 2147483648 | +-------------------+
ただし、潜在的な問題のほとんどはオペレーティングシステムに起因する可能性があるため、これで2038年問題が解決されるとは限りません。
また、 datetime2 が関係しているため、このコードのいずれも「西暦1万年問題」の影響を受けないわけではないことも指摘しておく必要があります。 データ型。上限は「9999-12-31」です。