GETUTCDATEがSYSDATETIMEOFFSETよりも早いのはなぜですか？

あるいは、マイクロソフトはどのようにしてタイムトラベルを可能にしたのですか？

このコードを考えてみましょう：

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はの前 @UTCに設定されますが、後の値になることもあります。（私はSQL Server 2008 R2とSQL Server 2016でこれを試しました。疑わしい出来事をキャッチするには、数回実行する必要があります。）

これは、単に丸めや精度の欠如の問題であるようには見えません。（実際、丸めは時々問題を「修正」するものだと思います。）サンプル実行の値は次のとおりです。

• オフセット
  • 2017-06-07 12：01：58.8801139 -05：00
• UTC
  • 2017-06-07 17：01：58.877
• オフセットからのUTC：
  • 2017-06-07 17：01：58.880

したがって、日時の精度では、.880を有効な値として使用できます。

でも、MicrosoftのGETUTCDATE例は、 SYS *値があることを示し、後に選択されているにもかかわらず、古い方法よりも早く：

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  
*/

これは、根本的なシステム情報が異なるためだと思います。誰かが詳細を確認して提供できますか？

MicrosoftのSYSDATETIMEOFFSETのドキュメントは、（感謝srutzky）「SQL ServerがGetSystemTimeAsFileTime（）は、Windows APIを使用して、日付と時刻の値を取得」と言うが、そのGETUTCDATEのドキュメントは、「値がのオペレーティングシステムに由来していることだけ言って、あまり具体的ですSQL Serverのインスタンスが実行されているコンピューター」。

（これは完全に学術的なものではありません。これによって引き起こされた小さな問題に遭遇しました。将来の精度向上を期待して、GETUTCDATEの代わりにSYSDATETIMEOFFSETを使用するようにいくつかのプロシージャをアップグレードしましたが、他のプロシージャがまだGETUTCDATEを使用しており、変換されたプロシージャのログを時折「ジャンプ」します。）

問題は、データ型の粒度/精度と値のソースの組み合わせです。

1つ目は、DATETIME3ミリ秒ごとにのみ正確/粒度です。したがって、例えば、より正確なデータ型からの変換DATETIMEOFFSETまたはDATETIME2最寄りミリ秒にしないであろうだけラウンドアップまたはダウン、それが異なる2ミリ秒とすることができます。

第二に、ドキュメントは値がどこから来たのか違いを示唆しているようです。SYS *関数は、高精度のFileTime関数を使用します。

SYSDATETIMEOFFSETドキュメントには次のように記載されています。

SQL Serverは、GetSystemTimeAsFileTime（）Windows APIを使用して日付と時刻の値を取得します。

GETUTCDATEのドキュメントには次のように記載されています。

この値は、SQL Serverのインスタンスが実行されているコンピューターのオペレーティングシステムから取得されます。

次に、About Timeのドキュメントでは、グラフに次の2つ（いくつか）のタイプが表示されます。

• システム時刻= "内部ハードウェアクロックから取得した年、月、日、時、秒、ミリ秒。"
• ファイル時間= "1601年1月1日からの100ナノ秒間隔の数。"

追加の手がかりは、StopWatchクラスの.NETドキュメントにあります（太字の斜体で強調）：

• ストップウォッチクラス

  ストップウォッチは、基になるタイマーメカニズムのタイマーティックをカウントすることによって経過時間を測定します。インストールされているハードウェアとオペレーティングシステムが高解像度のパフォーマンスカウンターをサポートしている場合、Stopwatchクラスはそのカウンターを使用して経過時間を測定します。それ以外の場合、Stopwatchクラスはシステムタイマーを使用して経過時間を測定します。

• Stopwatch.IsHighResolutionフィールド

  Stopwatchクラスで使用されるタイマーは、システムハードウェアとオペレーティングシステムによって異なります。ストップウォッチタイマーが高解像度のパフォーマンスカウンターに基づいている場合、IsHighResolutionはtrueです。それ以外の場合、IsHighResolutionはfalseです。これは、ストップウォッチタイマーがシステムタイマーに基づいていることを示します。

したがって、精度とソースの両方が異なる時間の「タイプ」は異なります。

しかし、それが非常に緩いロジックであっても、DATETIME値のソースとして両方のタイプの関数をテストすると、それが証明されます。質問からのクエリの次の適応は、この動作を示しています。

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;

戻り値：

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

上記の結果からわかるように、UTCとUTC2はどちらもDATETIMEデータ型です。@UTC2によって設定さSYSUTCDATETIME()れ、後に設定されます@Offset（これもSYS *関数から取得されます）が、その前に@UTCによって設定されGETUTCDATE()ます。まだ@UTC2前に来ているよう@UTCです。このオフセット部分は、まったく何にも関係ありません。

しかし、公平を期すために、これはまだ厳密な意味での証明ではありません。@MartinSmithがGETUTCDATE()呼び出しをトレースしたところ、次のことがわかりました。

このコールスタックには3つの興味深いものがあります。

1. IsはGetSystemTime()、ミリ秒まで正確な値を返す呼び出しで始まります。
2. これはDateFromPartsを使用します（つまり、変換する数式はなく、個々のピースを使用します）。
3. 下の方にQueryPerformanceCounterへの呼び出しがあります。これは、「修正」の手段として使用できる高解像度の差分カウンターです。長い間隔がゆっくりと同期しなくなると、一方のタイプを使用してもう一方のタイプを徐々に調整するという提案がいくつかあります（SOの.NET / C＃でティック精度のタイムスタンプを取得する方法を参照）。これはを呼び出しても表示されませんSYSDATETIMEOFFSET。

さまざまなタイプの時間、さまざまなソース、ドリフトなどに関して、ここには多くの優れた情報があります。高解像度のタイムスタンプの取得。

実際には、異なる精度の値を比較することは適切ではありません。あなたが持っている場合たとえば、2017-06-07 12:01:58.8770011そして2017-06-07 12:01:58.877、その後、どのように少ない精度の1未満、より大きいことを知っています、またはそれ以上の精度で値に等しいですか？それらを比較することは、あまり正確でない方が実際2017-06-07 12:01:58.8770000にはであると仮定しますが、それが本当かどうかは誰が知っていますか？リアルタイムはまたはのいずれ2017-06-07 12:01:58.8770005か2017-06-07 12:01:58.8770111でした。

ただし、DATETIMEデータ型がある場合は、SYS *関数の方がソースとして使用する必要があります。SYS*関数の方が精度が高いため、値の精度が低くなり、精度が低下した場合でも使用できます。そしてそれらの線に沿って、それを介してそれを調整するためだけにSYSUTCDATETIME()呼び出すのSYSDATETIMEOFFSET()ではなく、使用する方が理にかなっているようSWITCHOFFSET(@Offset, 0)です。