Atau, bagaimana Microsoft memungkinkan perjalanan waktu?
Pertimbangkan kode ini:
DECLARE @Offset datetimeoffset = sysdatetimeoffset();
DECLARE @UTC datetime = getUTCdate();
DECLARE @UTCFromOffset datetime = CONVERT(datetime,SWITCHOFFSET(@Offset,0));
SELECT
Offset = @Offset,
UTC = @UTC,
UTCFromOffset = @UTCFromOffset,
TimeTravelPossible = CASE WHEN @UTC < @UTCFromOffset THEN 1 ELSE 0 END;
@Offset
diatur sebelumnya @UTC
, namun terkadang memiliki nilai nanti . (Saya sudah mencoba ini di SQL Server 2008 R2 dan SQL Server 2016. Anda harus menjalankannya beberapa kali untuk menangkap kejadian yang mencurigakan.)
Ini tampaknya bukan hanya masalah pembulatan atau kurangnya presisi. (Sebenarnya, saya pikir pembulatan adalah apa yang "memperbaiki" masalah sesekali.) Nilai-nilai untuk menjalankan sampel adalah sebagai berikut:
- Mengimbangi
- 2017-06-07 12: 01: 58.8801139 -05: 00
- UTC
- 2017-06-07 17: 01: 58.877
- UTC Dari Offset:
- 2017-06-07 17: 01: 58.880
Jadi, ketelitian datetime memungkinkan .880 sebagai nilai yang valid.
Bahkan contoh Microsoft GETUTCDATE menunjukkan nilai SYS * lebih lambat dari metode yang lebih lama, meskipun telah SELECTed sebelumnya :
SELECT 'SYSDATETIME() ', SYSDATETIME(); SELECT 'SYSDATETIMEOFFSET()', SYSDATETIMEOFFSET(); SELECT 'SYSUTCDATETIME() ', SYSUTCDATETIME(); SELECT 'CURRENT_TIMESTAMP ', CURRENT_TIMESTAMP; SELECT 'GETDATE() ', GETDATE(); SELECT 'GETUTCDATE() ', GETUTCDATE(); /* Returned: SYSDATETIME() 2007-05-03 18:34:11.9351421 SYSDATETIMEOFFSET() 2007-05-03 18:34:11.9351421 -07:00 SYSUTCDATETIME() 2007-05-04 01:34:11.9351421 CURRENT_TIMESTAMP 2007-05-03 18:34:11.933 GETDATE() 2007-05-03 18:34:11.933 GETUTCDATE() 2007-05-04 01:34:11.933 */
Saya kira ini karena mereka berasal dari sistem informasi dasar yang berbeda. Adakah yang bisa mengkonfirmasi dan memberikan rincian?
Dokumentasi SYSDATETIMEOFFSET Microsoft mengatakan "SQL Server memperoleh nilai tanggal dan waktu dengan menggunakan GetSystemTimeAsFileTime () Windows API" (terima kasih srutzky), tetapi dokumentasi GETUTCDATE mereka jauh lebih spesifik, hanya mengatakan bahwa nilai "berasal dari sistem operasi sistem komputer tempat instance dari SQL Server berjalan ".
(Ini bukan sepenuhnya akademis. Saya mengalami masalah kecil yang disebabkan oleh ini. Saya memperbarui beberapa prosedur untuk menggunakan SYSDATETIMEOFFSET alih-alih GETUTCDATE, dengan harapan untuk presisi yang lebih besar di masa mendatang, tetapi saya mulai mendapatkan pesanan aneh karena prosedur lain dilakukan masih menggunakan GETUTCDATE dan kadang-kadang "melompati" prosedur saya yang dikonversi dalam log.)