Почему GETUTCDATE раньше, чем SYSDATETIMEOFFSET?

В качестве альтернативы, как Microsoft сделала возможным путешествие во времени?

Рассмотрим этот код:

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
• универсальное глобальное время
  • 2017-06-07 17: 01: 58.877
• UTC от смещения:
  • 2017-06-07 17: 01: 58.880

Таким образом, точность даты и времени допускает 0,880 в качестве допустимого значения.

Даже примеры GETUTCDATE от Microsoft показывают, что значения 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 гласит: «SQL Server получает значения даты и времени с помощью Windows API GetSystemTimeAsFileTime ()» (спасибо srutzky), но их документация GETUTCDATE гораздо менее конкретна, говоря только о том, что «значение получено из операционной системы компьютер, на котором работает экземпляр SQL Server ".

(Это не совсем академично. Я столкнулся с незначительной проблемой, вызванной этим. Я обновлял некоторые процедуры, чтобы использовать SYSDATETIMEOFFSET вместо GETUTCDATE, в надежде на большую точность в будущем, но я начал получать странный порядок, потому что другие процедуры были все еще использую GETUTCDATE и иногда "забегаю вперед" из моих преобразованных процедур в журналах.)

Проблема заключается в сочетании гранулярности / точности типов данных и источника значений.

Во-первых, DATETIMEэто только точное / гранулированное значение каждые 3 миллисекунды. Следовательно, преобразование из более точного типа данных , такие как DATETIMEOFFSETили DATETIME2не будет просто круглым вверх или вниз до ближайшей миллисекунды, это может быть 2 миллисекунды разные.

Во-вторых, документация подразумевает разницу в том, откуда берутся значения. Функции SYS * используют высокоточные функции FileTime.

Документация SYSDATETIMEOFFSET гласит:

SQL Server получает значения даты и времени с помощью Windows API GetSystemTimeAsFileTime ().

в то время как документация GETUTCDATE гласит:

Это значение является производным от операционной системы компьютера, на котором работает экземпляр SQL Server.

Затем в документации « О времени» диаграмма показывает следующие два (из нескольких) типов:

• Системное время = «Год, месяц, день, час, секунда и миллисекунда, взятые из внутренних аппаратных часов».
• File Time = «Количество интервалов в 100 наносекунд с 1 января 1601 года».

Дополнительные подсказки находятся в документации .NET для StopWatchкласса (выделение выделено жирным курсивом):

• Класс секундомера

  Секундомер измеряет прошедшее время, подсчитывая отметки времени в базовом механизме таймера. Если установленное оборудование и операционная система поддерживают счетчик производительности с высоким разрешением, то класс секундомера использует этот счетчик для измерения прошедшего времени. В противном случае класс Секундомер использует системный таймер для измерения прошедшего времени.

• Секундомер.IsHighResolution Field

  Таймер, используемый классом секундомера, зависит от системного оборудования и операционной системы. 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()звонок и обнаружил следующее:

Я вижу три интересные вещи в этом стеке вызовов:

1. Is начинается с вызова, GetSystemTime()который возвращает значение с точностью до миллисекунд.
2. Он использует DateFromParts (то есть нет формулы для преобразования, просто используйте отдельные части).
3. Есть вызов QueryPerformanceCounter внизу. Это счетчик разности высокого разрешения, который можно использовать как средство «коррекции». Я видел некоторые предложения использовать один тип для настройки другого с течением времени, так как длинные интервалы медленно теряют синхронизацию (см. Как получить временную метку точности тиков в .NET / C #? На SO). Это не отображается при звонке SYSDATETIMEOFFSET.

Здесь много полезной информации о различных типах времени, различных источниках, дрейфе и т. Д.: Получение меток времени с высоким разрешением .

Действительно, неуместно сравнивать значения разной точности. Например, если у вас есть 2017-06-07 12:01:58.8770011и 2017-06-07 12:01:58.877, то как узнать, что значение с меньшей точностью больше, меньше или равно значению с большей точностью? Сравнение их предполагает, что на самом деле менее точный 2017-06-07 12:01:58.8770000, но кто знает, правда это или нет? Реальное время могло быть или 2017-06-07 12:01:58.8770005или 2017-06-07 12:01:58.8770111.

Однако, если у вас есть DATETIMEтипы данных, вам следует использовать функции SYS * в качестве источника, поскольку они более точны, даже если вы теряете некоторую точность, поскольку значение принудительно переводится в менее точный тип. И в этом отношении, кажется, имеет больше смысла использовать, SYSUTCDATETIME()а не вызывать SYSDATETIMEOFFSET()только для настройки через SWITCHOFFSET(@Offset, 0).