Sinon, comment Microsoft a-t-il rendu possible le voyage dans le temps?
Considérez ce code:
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
est défini avant @UTC
, mais il a parfois une valeur ultérieure . (J'ai essayé cela sur SQL Server 2008 R2 et SQL Server 2016. Vous devez l'exécuter plusieurs fois pour détecter les occurrences suspectes.)
Cela ne semble pas être simplement une question d'arrondi ou de manque de précision. (En fait, je pense que l'arrondi est ce qui "résout" le problème de temps en temps.) Les valeurs pour un exemple d'exécution sont les suivantes:
- Décalage
- 2017-06-07 12: 01: 58.8801139 -05: 00
- UTC
- 2017-06-07 17: 01: 58.877
- UTC à partir du décalage:
- 2017-06-07 17: 01: 58.880
La précision datetime autorise donc le .880 comme valeur valide.
Même les exemples GETUTCDATE de Microsoft montrent que les valeurs SYS * sont plus récentes que les anciennes méthodes, bien qu'elles aient été sélectionnées plus tôt :
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 */
Je suppose que c'est parce qu'ils proviennent de différentes informations système sous-jacentes. Quelqu'un peut-il confirmer et fournir des détails?
La documentation SYSDATETIMEOFFSET de Microsoft indique que "SQL Server obtient les valeurs de date et d'heure en utilisant l'API Windows GetSystemTimeAsFileTime ()" (merci srutzky), mais leur documentation GETUTCDATE est beaucoup moins spécifique, indiquant seulement que la "valeur est dérivée du système d'exploitation de la ordinateur sur lequel s'exécute l'instance de SQL Server ".
(Ce n'est pas entièrement académique. J'ai rencontré un problème mineur causé par cela. J'étais en train de mettre à niveau certaines procédures pour utiliser SYSDATETIMEOFFSET au lieu de GETUTCDATE, dans l'espoir d'une plus grande précision à l'avenir, mais j'ai commencé à obtenir des commandes étranges parce que d'autres procédures étaient toujours en utilisant GETUTCDATE et parfois "sauter en avant" de mes procédures converties dans les journaux.)