Mengapa GETUTCDATE lebih awal dari SYSDATETIMEOFFSET?

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;

@Offsetdiatur 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.)

Masalahnya adalah kombinasi rincian data / akurasi dan sumber nilai.

Pertama, DATETIMEhanya akurat / terperinci untuk setiap 3 milidetik. Oleh karena itu, mengubah dari tipe data yang lebih tepat seperti DATETIMEOFFSETatau DATETIME2tidak hanya membulatkan ke atas atau ke bawah ke milidetik terdekat, bisa jadi berbeda 2 milidetik.

Kedua, dokumentasi tampaknya menyiratkan perbedaan dari mana nilai-nilai itu berasal. Fungsi SYS * menggunakan fungsi FileTime presisi tinggi.

Dokumentasi SYSDATETIMEOFFSET menyatakan:

SQL Server memperoleh nilai tanggal dan waktu dengan menggunakan API Windows GetSystemTimeAsFileTime ().

sedangkan dokumentasi GETUTCDATE menyatakan:

Nilai ini berasal dari sistem operasi komputer tempat instance SQL Server berjalan.

Kemudian, dalam dokumentasi About Time , bagan menunjukkan dua (dari beberapa) jenis berikut:

• System Time = "Tahun, bulan, hari, jam, detik, dan milidetik, diambil dari jam perangkat keras internal."
• File Time = "Jumlah interval 100 nanodetik sejak 1 Januari 1601."

Petunjuk tambahan ada dalam dokumentasi .NET untuk StopWatchkelas (penekanan pada huruf tebal miring):

• Kelas Stopwatch

  Stopwatch mengukur waktu yang berlalu dengan menghitung kutu timer dalam mekanisme timer yang mendasarinya. Jika perangkat keras dan sistem operasi yang diinstal mendukung penghitung kinerja resolusi tinggi, maka kelas Stopwatch menggunakan penghitung itu untuk mengukur waktu yang berlalu. Jika tidak, kelas Stopwatch menggunakan timer sistem untuk mengukur waktu yang berlalu.

• Stopwatch.IsHighResolution Field

  Timer yang digunakan oleh kelas Stopwatch tergantung pada perangkat keras sistem dan sistem operasi. IsHighResolution benar jika timer Stopwatch didasarkan pada penghitung kinerja resolusi tinggi. Jika tidak, IsHighResolution salah , yang menunjukkan bahwa penghitung waktu Stopwatch didasarkan pada pengatur waktu sistem .

Oleh karena itu, ada "jenis" waktu yang berbeda yang memiliki presisi dan sumber yang berbeda pula.

Tetapi, bahkan jika itu adalah logika yang sangat longgar, menguji kedua jenis fungsi sebagai sumber untuk DATETIMEnilai membuktikannya. Adaptasi kueri dari pertanyaan berikut menunjukkan perilaku ini:

DECLARE @Offset DATETIMEOFFSET = SYSDATETIMEOFFSET(),
        @UTC2 DATETIME = SYSUTCDATETIME(),
        @UTC DATETIME = GETUTCDATE();
DECLARE @UTCFromOffset DATETIME = CONVERT(DATETIME, SWITCHOFFSET(@Offset, 0));
SELECT
    Offset = @Offset,
    UTC2 = @UTC2,
    UTC = @UTC,
    UTCFromOffset = @UTCFromOffset,
    TimeTravelPossible = CASE WHEN @UTC < @UTCFromOffset THEN 1 ELSE 0 END,
    TimeTravelPossible2 = CASE WHEN @UTC2 < @UTCFromOffset THEN 1 ELSE 0 END;

Pengembalian:

Offset                 2017-06-07 17:50:49.6729691 -04:00
UTC2                   2017-06-07 21:50:49.673
UTC                    2017-06-07 21:50:49.670
UTCFromOffset          2017-06-07 21:50:49.673
TimeTravelPossible     1
TimeTravelPossible2    0

Seperti yang Anda lihat dalam hasil di atas, UTC dan UTC2 keduanya DATETIMEtipe data. @UTC2diatur melalui SYSUTCDATETIME()dan diatur setelah @Offset(juga diambil dari fungsi SYS *), tetapi sebelum @UTCyang diatur melalui GETUTCDATE(). Namun, @UTC2tampaknya datang sebelumnya @UTC. Bagian OFFSET ini sama sekali tidak terkait dengan apa pun.

NAMUN, untuk bersikap adil, ini masih bukan bukti dalam arti yang ketat. @MartinSmith melacak GETUTCDATE()panggilan dan menemukan yang berikut:

Saya melihat tiga hal menarik dalam tumpukan panggilan ini:

1. Dimulai dengan panggilan GetSystemTime()yang mengembalikan nilai yang hanya tepat hingga milidetik.
2. Menggunakan DateFromParts (yaitu tidak ada rumus untuk dikonversi, cukup gunakan masing-masing bagian)
3. Ada panggilan ke QueryPerformanceCounter ke bagian bawah. Ini adalah penghitung perbedaan resolusi tinggi yang dapat digunakan sebagai sarana "koreksi". Saya telah melihat beberapa saran untuk menggunakan satu jenis untuk menyesuaikan yang lain dari waktu ke waktu sebagai interval lama perlahan-lahan tidak sinkron (lihat Bagaimana cara mendapatkan cap waktu presisi kutu dalam. NET / C #? Pada SO). Ini tidak muncul saat menelepon SYSDATETIMEOFFSET.

Ada banyak info bagus di sini mengenai berbagai jenis waktu, sumber berbeda, pergeseran, dll: Memperoleh perangko waktu resolusi tinggi .

Sungguh, tidak tepat untuk membandingkan nilai-nilai dari berbagai ketentuan. Misalnya, jika Anda memiliki 2017-06-07 12:01:58.8770011dan 2017-06-07 12:01:58.877, lalu bagaimana Anda tahu bahwa yang memiliki presisi kurang lebih besar, kurang dari, atau sama dengan nilai dengan presisi lebih? Membandingkan mereka mengasumsikan bahwa yang kurang tepat sebenarnya 2017-06-07 12:01:58.8770000, tetapi siapa yang tahu apakah itu benar atau tidak? Waktu sebenarnya bisa berupa 2017-06-07 12:01:58.8770005atau 2017-06-07 12:01:58.8770111.

Namun, jika Anda memiliki DATETIMEtipe data, maka Anda harus menggunakan fungsi SYS * sebagai sumber karena lebih akurat, bahkan jika Anda kehilangan beberapa presisi karena nilainya dipaksa menjadi tipe yang kurang tepat. Dan sejalan dengan itu, tampaknya lebih masuk akal untuk menggunakan SYSUTCDATETIME()daripada SYSDATETIMEOFFSET()hanya menelepon untuk menyesuaikannya SWITCHOFFSET(@Offset, 0).