Pourquoi GETUTCDATE est-il antérieur à SYSDATETIMEOFFSET?

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;

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

Le problème est une combinaison de granularité / précision du type de données et de la source des valeurs.

Tout d'abord, il DATETIMEn'est précis / granulaire que toutes les 3 millisecondes. Par conséquent, la conversion à partir d'un type de données plus précis, tel que DATETIMEOFFSETou DATETIME2ne sera pas simplement arrondi à la milliseconde la plus proche, pourrait être différente de 2 millisecondes.

Deuxièmement, la documentation semble impliquer une différence dans la provenance des valeurs. Les fonctions SYS * utilisent les fonctions FileTime de haute précision.

La documentation SYSDATETIMEOFFSET indique:

SQL Server obtient les valeurs de date et d'heure à l'aide de l'API Windows GetSystemTimeAsFileTime ().

tandis que la documentation GETUTCDATE indique:

Cette valeur est dérivée du système d'exploitation de l'ordinateur sur lequel s'exécute l'instance de SQL Server.

Ensuite, dans la documentation À propos de l'heure , un graphique présente les deux (parmi plusieurs) types suivants:

• Heure système = "Année, mois, jour, heure, seconde et milliseconde, extraits de l'horloge matérielle interne."
• File Time = "Le nombre d'intervalles de 100 nanosecondes depuis le 1er janvier 1601."

Des indices supplémentaires sont dans la documentation .NET pour la StopWatchclasse (accentuation en gras italique le mien):

• Classe chronomètre

  Le chronomètre mesure le temps écoulé en comptant les tics du minuteur dans le mécanisme de minuteur sous-jacent. Si le matériel et le système d'exploitation installés prennent en charge un compteur de performances haute résolution, la classe Chronomètre utilise ce compteur pour mesurer le temps écoulé. Sinon, la classe Chronomètre utilise le minuteur système pour mesurer le temps écoulé.

• Chronomètre.IsHighResolution Field

  Le minuteur utilisé par la classe Chronomètre dépend du matériel système et du système d'exploitation. IsHighResolution est vrai si le chronomètre est basé sur un compteur de performances haute résolution. Sinon, IsHighResolution est false , ce qui indique que le chronomètre est basé sur le chronomètre système .

Par conséquent, il existe différents «types» de temps qui ont à la fois des précisions et des sources différentes.

Mais, même si c'est une logique très lâche, tester les deux types de fonctions comme sources de la DATETIMEvaleur le prouve. L'adaptation suivante de la requête de la question montre ce comportement:

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;

Retour:

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

Comme vous pouvez le voir dans les résultats ci-dessus, UTC et UTC2 sont tous deux des DATETIMEtypes de données. @UTC2est défini via SYSUTCDATETIME()et est défini après @Offset(également tiré d'une fonction SYS *), mais avant @UTClequel est défini via GETUTCDATE(). Pourtant, @UTC2semble venir avant @UTC. La partie OFFSET de tout cela n'a aucun rapport avec quoi que ce soit.

CEPENDANT, pour être juste, ce n'est toujours pas une preuve au sens strict. @MartinSmith a retracé l' GETUTCDATE()appel et a trouvé ce qui suit:

Je vois trois choses intéressantes dans cette pile d'appels:

1. Is commence par un appel GetSystemTime()auquel renvoie une valeur qui n'est précise que jusqu'aux millisecondes.
2. Il utilise DateFromParts (c'est-à-dire aucune formule à convertir, utilisez simplement les pièces individuelles).
3. Il y a un appel à QueryPerformanceCounter vers le bas. Il s'agit d'un compteur de différence à haute résolution qui pourrait être utilisé comme moyen de "correction". J'ai vu une suggestion d'utiliser un type pour ajuster l'autre au fil du temps car de longs intervalles se désynchronisent lentement (voir Comment obtenir l'horodatage de la précision des ticks dans .NET / C #? Sur SO). Cela n'apparaît pas lors de l'appel SYSDATETIMEOFFSET.

Il y a beaucoup de bonnes informations ici concernant les différents types de temps, les différentes sources, la dérive, etc.: Acquérir des horodatages haute résolution .

En réalité, il n'est pas approprié de comparer les valeurs de différentes précisions. Par exemple, si vous avez 2017-06-07 12:01:58.8770011et 2017-06-07 12:01:58.877, alors comment savez-vous que celui avec moins de précision est supérieur, inférieur ou égal à la valeur avec plus de précision? Les comparer suppose que le moins précis est en fait 2017-06-07 12:01:58.8770000, mais qui sait si c'est vrai ou non? Le temps réel aurait pu être soit 2017-06-07 12:01:58.8770005ou 2017-06-07 12:01:58.8770111.

Cependant, si vous avez des DATETIMEtypes de données, vous devez utiliser les fonctions SYS * comme source car elles sont plus précises, même si vous perdez une certaine précision car la valeur est forcée dans un type moins précis. Et dans ce sens, il semble plus logique d'utiliser SYSUTCDATETIME()plutôt que d'appeler SYSDATETIMEOFFSET()uniquement pour l'ajuster via SWITCHOFFSET(@Offset, 0).