Anda mungkin telah memperhatikan bahwa SQL Server tidak memiliki yang setara dengan UNIX_TIMESTAMP() MySQL fungsi.
Namun, tidak sulit untuk mengembalikan stempel waktu Unix di SQL Server.
Stempel waktu Unix (juga dikenal sebagai waktu Unix Epoch, waktu Unix, atau waktu POSIX) hanyalah jumlah detik yang telah berlalu sejak 00:00:00 Kamis, 1 Januari 1970, Waktu Universal Terkoordinasi (UTC). Oleh karena itu, di SQL Server kita dapat menggunakan beberapa fungsi T-SQL untuk mengembalikan ini.
Stempel Waktu SQL Server Unix
Berikut cara mengembalikan stempel waktu Unix di SQL Server.
SELECT DATEDIFF(SECOND,'1970-01-01', GETUTCDATE()) AS 'SQL Server Result';
Hasil:
+---------------------+ | SQL Server Result | |---------------------| | 1560833178 | +---------------------+
Jadi kita bisa menggunakan DATEDIFF() berfungsi untuk mengembalikan selisih detik antara 1970-01-01 dan sekarang. Kami menggunakan GETUTCDATE() berfungsi untuk mengembalikan tanggal dan waktu saat ini dalam waktu UTC.
Kode ini akan berfungsi hingga tahun 2038 ('2038-01-19 03:14:07' tepatnya). Untuk cap waktu Unix setelah itu, Anda perlu sedikit mengubah kode. Jika Anda memerlukan stempel waktu Unix yang melewati tanggal tersebut, baca terus.
Setara dengan Stempel Waktu MySQL Unix
Sebagai perbandingan, jika saya menjalankan UNIX_TIMESTAMP() MySQL pada saat yang sama, saya mendapatkan ini:
SELECT UNIX_TIMESTAMP() AS 'MySQL Result';
Hasil:
+--------------+ | MySQL Result | +--------------+ | 1560833178 | +--------------+
Hasil yang sama. MySQL mengembalikan hasilnya sebagai bilangan bulat yang tidak ditandatangani. Namun, jika argumen tanggal (opsional) diteruskan, argumen tersebut mendukung rentang yang sama dengan TIMESTAMP tipe data.
Mengembalikan Milidetik
Jika Anda perlu mengembalikan stempel waktu Unix dengan presisi lebih tinggi, katakanlah, jumlah milidetik sejak '1970-01-01 00:00:00.000' UTC, Anda harus menukar DATEDIFF() fungsi untuk DATEDIFF_BIG() .
Ini karena DATEDIFF() mengembalikan int , yang terlalu kecil untuk menangani jumlah milidetik sejak 1970. DATEDIFF_BIG() fungsi di sisi lain, mengembalikan bigint . yang ditandatangani , yang lebih dari cukup untuk menangani milidetik.
SELECT DATEDIFF_BIG(MILLISECOND,'1970-01-01 00:00:00.000', SYSUTCDATETIME()) Milliseconds;
Hasil:
+----------------+ | Milliseconds | |----------------| | 1560835305461 | +----------------+
Mengembalikan Nanodetik
Berikut contoh lain, kali ini hingga nanodetik sejak '1970-01-01 00:00:00,0000000' UTC.
SELECT DATEDIFF_BIG(NANOSECOND,'1970-01-01 00:00:00.0000000', SYSUTCDATETIME()) Nanoseconds;
Hasil:
+---------------------+ | Nanoseconds | |---------------------| | 1560835321500279300 | +---------------------+
Masalah Tahun 2038
Mengembalikan milidetik, mikrodetik, dan nanodetik semuanya baik dan baik, tetapi sebenarnya, ini bukan waktu Unix Epoch yang sebenarnya. Waktu Unix Epoch adalah jumlah detik sejak '1970-01-01 00:00:00'.
Namun, DATEDIFF_BIG() masih bisa berguna ketika mengembalikan waktu Unix Epoch yang ketat. Secara khusus, ini dapat membantu database Anda mengatasi masalah 2038. Dalam hal ini, apa pun setelah '2038-01-19 03:14:07' harus dikembalikan sebagai besar (sebuah bilangan bulat 8 byte). Ini karena jumlah detik akan terlalu besar untuk int tipe data (4 byte integer). int tipe data hanya mencapai 2.147.483.647, sedangkan besar naik menjadi 9.223.372.036.854.775.807.
Oleh karena itu, untuk mengembalikan stempel waktu Unix melewati '2038-01-19 03:14:07', gunakan DATEDIFF_BIG() fungsi alih-alih DATEDIFF() .
Untuk mendemonstrasikannya, berikut adalah contoh penggunaan DATEDIFF() untuk mengembalikan waktu Unix tepat pada tanggal/waktu tersebut:
SELECT DATEDIFF(SECOND,'1970-01-01', '2038-01-19 03:14:07') AS 'Unix Epoch time';
Hasil:
+-------------------+ | Unix Epoch time | |-------------------| | 2147483647 | +-------------------+
Sejauh ini baik. Hasil ini berada dalam int kisaran -2.147.483.648 hingga 2.147.483.647 (walaupun tepat di batas atas) sehingga hasil yang benar dikembalikan.
Tapi inilah yang terjadi jika kita meningkatkannya satu detik:
SELECT DATEDIFF(SECOND,'1970-01-01', '2038-01-19 03:14:08') AS 'Unix Epoch time';
Hasil:
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.
Kami mendapatkan kesalahan karena nilai yang dikembalikan akan berada di luar int jangkauan.
Jadi seperti yang disebutkan, yang perlu kita lakukan hanyalah menukar DATEDIFF() untuk DATEDIFF_BIG() :
SELECT DATEDIFF_BIG(SECOND,'1970-01-01', '2038-01-19 03:14:08') AS 'Unix Epoch time';
Hasil:
+-------------------+ | Unix Epoch time | |-------------------| | 2147483648 | +-------------------+
Namun, ini tidak serta merta menyelesaikan masalah sepanjang tahun 2038, karena sebagian besar masalah potensial mungkin berasal dari sistem operasi.
Saya juga harus menunjukkan bahwa tidak satu pun dari kode ini tidak serta merta kebal terhadap “Masalah Tahun 10.000”, karena melibatkan datetime2 tipe data, yang memiliki rentang atas '9999-12-31'.
