Question

La FILETIME est compté à partir du 1 janvier 1601 (probablement le début de la journée) selon la documentation de Microsoft, mais est-ce que cela inclut les secondes intercalaires?

Était-ce utile?

La solution

La question ne devrait pas être si FILETIME inclut des secondes intercalaires.

Cela devrait être:

  

Les personnes, les fonctions et les bibliothèques qui interprètent un FILETIME (c'est-à-dire FileTimeToSystemTime ) incluent-elles des secondes intercalaires dans le calcul de la durée?

La réponse simple est "non" . FileTimeToSystemTime renvoie les secondes sous la forme 0..59 .

La réponse la plus simple est: " Bien sûr que non, comment pourrait-il? ".

Ma machine Windows 2000 ne sait pas qu'il s'est ajouté 2 secondes bissextiles au cours de la décennie écoulée depuis sa sortie. Toute interprétation qu’il donne d’un FILETIME est fausse.

Enfin, au lieu de nous appuyer sur la logique, nous pouvons déterminer, par observation directe expérimentale, la réponse à la question des affiches:

var
    systemTime: TSystemTime;
    fileTime: TFileTime;
begin
    //Construct a system-time for the 12/31/2008 11:59:59 pm
    ZeroMemory(@systemTime, SizeOf(systemTime));
    systemtime.wYear := 2008;
    systemTime.wMonth := 12;
    systemTime.wDay := 31;
    systemTime.wHour := 23;
    systemtime.wMinute := 59;
    systemtime.wSecond := 59;

    //Convert it to a file time
    SystemTimeToFileTime(systemTime, {var}fileTime);

    //There was a leap second 12/31/2008 11:59:60 pm
    //Add one second to our filetime to reach the leap second
    filetime.dwLowDateTime := fileTime.dwLowDateTime+10000000; //10,000,000 * 100ns = 1s

    //Convert the filetime, sitting on a leap second, to a displayable system time
    FileTimeToSystemTime(fileTime, {var}systemTime);

    //And now print the system time
    ShowMessage(DateTimeToStr(SystemTimeToDateTime(systemTime)));

Ajouter une seconde à

12/31/2008 11:59:59pm

donne

1/1/2009 12:00:00am

plutôt que

1/1/2009 11:59:60pm

Q.E.D.

L’affiche originale pourrait ne pas l’aimer, mais dieu l’a intentionnellement arrangée pour qu’une année ne soit pas divisible par jour. Il l'a fait juste pour bousiller les programmeurs.

Autres conseils

Voici quelques informations supplémentaires sur les raisons de cette particularité. la date a été choisie.

  

La structure FILETIME enregistre le temps dans   la forme des intervalles de 100 nanosecondes   depuis le 1 er janvier 1601. Pourquoi était-ce   date choisie?

     

Le calendrier grégorien fonctionne sur un   Cycle de 400 ans, et 1601 est le premier   année du cycle qui était actif à   au moment où Windows NT était en cours   conçu. En d'autres termes, c'était   choisi pour faire le calcul sortir   bien.

     

J'ai en fait le courrier électronique de Dave   Coutelier confirmant cela.

Il ne peut y avoir de réponse unique à cette question sans d'abord décider: Que compte réellement FILETIME Windows? La documentation Microsoft dit que cela compte avec des intervalles de 100 nanosecondes depuis 1601 UTC, mais cela pose problème.

Aucune forme de temps coordonné au niveau international n'existait avant 1960. Le nom UTC lui-même n'apparaît dans aucune littérature antérieure à 1964. Le nom UTC en tant que désignation officielle n'existait pas avant 1970. Mais il empire. L’Observatoire royal de Greenwich n’a été établi qu’en 1676, ce qui fait que même d’essayer d’interpréter FILETIME comme GMT n’a pas de sens clair, et c’est seulement vers cette époque que les horloges à pendule munies d’échappements précis ont commencé à donner une précision de 1 seconde.

Si FILETIME est interprété comme une moyenne de secondes solaires, le nombre de secondes intercalées depuis 1601 est égal à zéro, car l’UT n’a pas de secondes intercalaires. Si FILETIME est interprété comme s'il y avait eu des chronomètres atomiques, le nombre de secondes intercalaires depuis 1601 est d'environ -60 (c'est-à-dire négatif de 60 secondes intercalaires).

C’est l’histoire ancienne, qu’en est-il de l’époque des chronomètres atomiques? Ce n'est pas mieux parce que les gouvernements nationaux n'ont pas fait la distinction entre les secondes solaires moyennes et les secondes SI. Depuis une décennie, l’UIT-R discute de l’abandon des secondes intercalaires, mais n’a pas atteint le consensus international. Une partie de la raison de cela peut être vu dans la javascript sur cette page (voir également le lien delta-T sur cette page pour parcelles de l'histoire ancienne). Comme les gouvernements nationaux n’ont pas fait de distinction claire, toute tentative de définir le nombre de secondes écoulées depuis 1972 risque d’être invalide au regard des lois de certaines juridictions. Les délégués à l'UIT-R sont conscients de cette complexité, de même que les membres du comité POSIX. Tant que les questions diplomatiques ne seront pas réglées, tant que les gouvernements nationaux et les normes internationales ne feront pas la distinction et le choix entre secondes solaires et secondes SI, il n’ya plus guère d’espoir que les normes informatiques puissent suivre.

Les secondes intercalaires sont ajoutées de façon imprévisible par l’IERS. 23 secondes ont été ajoutées depuis 1972, année où l’UTC et les secondes intercalaires ont été définis. Selon Wikipedia, "étant donné que le taux de rotation de la Terre est imprévisible à long terme, il est impossible de prévoir leur besoin plus de six mois à l'avance".

Etant donné que vous devez conserver un historique de l'insertion de secondes intercalaires et mettre à jour le système d'exploitation pour conserver une référence indiquant le moment où elles ont été insérées, et que la différence est si faible, il est juste de ne pas s'attendre à un général- objectif OS pour compenser les secondes intercalaires.

De plus, la dérive régulière de la simple horloge électronique de votre PC par rapport à l’UTC est bien supérieure à la compensation requise pour les secondes intercalaires. Si vous avez besoin du genre de précision nécessaire pour compenser les secondes intercalaires, vous ne devez pas utiliser la très imprécise horloge du PC.

Auparavant, la réponse à cette question était non, mais elle est devenue: OUI, en quelque sorte, parfois ...

Par l'article de blog de l'équipe de mise en réseau Windows :

  

À partir de Server 2019 et de Windows 10 octobre [2018], les API de mise à jour prennent désormais en compte toutes les secondes intercalaires connues du système d'exploitation lors de la conversion de FILETIME en SystemTime.

Étant donné qu'aucune seconde intercalaire n'a été émise depuis l'ajout de cette fonctionnalité, le système d'exploitation n'a toujours pas connaissance de secondes intercalaires. Cependant, lorsque la prochaine seconde sautée officielle arrivera au monde, les ordinateurs Windows sur lesquels cette nouvelle fonctionnalité sera activée en garderont trace, de sorte que les valeurs FILETIME seront compensées par le nombre de secondes intercalaires écoulées. l'ordinateur au moment où ils sont interprétés.

L'article de blog décrit ensuite:

  

Aucune modification n’est apportée à FILETIME. Il représente toujours le nombre d'intervalles de 100 ns depuis le début de l'époque. Ce qui a changé, c’est l’interprétation de ce nombre lorsqu’il est converti en SYSTEMTIME et inversement. Voici une liste des API concernées:

     
      
  • GetSystemTime
  •   
  • GetLocalTime
  •   
  • FileTimeToSystemTime
  •   
  • FileTimeToLocalTime
  •   
  • SystemTimeToFileTime
  •   
  • SetSystemTime
  •   
  • SetLocalTime
  •   
     

Avant cette version, SYSTEMTIME avait une valeur valide pour wSecond comprise entre 0 et 59. SYSTEMTIME a maintenant été mis à jour pour permettre une valeur de 60, à condition que l'année, le mois et le jour représentent le jour où une seconde intercalaire est valide. / p>      

...

     

Pour recevoir les 60 secondes dans la structure SYSTEMTIME, un processus doit explicitement s’inscrire.

Notez que l’inclusion s’applique au comportement dans les fonctions répertoriées sur la manière dont un FILETIME est mappé à un SYSTEMTIME . Que vous choisissiez ou non de participer, le système d’exploitation compensera toujours les valeurs de FILETIME en fonction des secondes intercalaires dont il a connaissance.

En ce qui concerne la compatibilité, l'article indique:

  

Les applications qui reposent sur des infrastructures tierces doivent s’assurer que leur implémentation sous Windows appelle également les API correctes pour calculer l’heure correcte, sinon l'application affichera une heure erronée.

Et fournit également des liens vers un article précédent décrivant comment désactiver l'intégralité de la fonctionnalité, comme suit:

  

... vous pouvez revenir au comportement précédent du système d'exploitation et désactiver les secondes intercalaires dans le tableau en ajoutant la clé de registre suivante:

     
      
  • HKLM: \ SYSTEM \ CurrentControlSet \ Control \ LeapSecondInformation
  •   
  • Type: "REG_DWORD"
  •   
  • Nom: activé
  •   
  • Valeur: 0 Désactive le paramètre à l'échelle du système
  •   
  • Valeur: 1 Active le paramètre à l'échelle du système
  •   
     

Ensuite, redémarrez votre système.

Un résumé très brut:

UTC = (temps atomique) + (secondes intercalaires) ~~ (temps solaire moyen)

La documentation de MS indique spécifiquement "UTC" et doit donc inclure les secondes intercalaires. Comme toujours avec MS, votre kilométrage peut varier.

Selon ces comment . est totalement inconscient des secondes intercalaires. Si vous ajoutez 24 * 60 * 60 secondes à une heure FILETIME qui représente 1h39:45 aujourd'hui, vous obtenez une heure FILETIME qui représente 1h39:45 demain, quoi qu'il arrive.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top