В качестве альтернативы, как 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 и иногда "забегаю вперед" из моих преобразованных процедур в журналах.)