Comment un fichier a-t-il pu être "créé" en 1641?
Il y a quelques années, je suis tombé sur ce fichier sur notre serveur de fichiers.
Et je me demande comment un fichier peut dire qu'il a été créé en 1641? Autant que je sache, le temps passé sur pc est défini par le nombre de secondes écoulées depuis le 1er janvier 1970. Si cet index disparaît, vous pouvez obtenir le 31 décembre 1969 (l'index dit probablement -1), mais je suis perplexe à ce sujet. date apparemment aléatoire, antérieure même à la fondation des États-Unis d’Amérique.
Alors, comment un fichier pourrait-il être daté de 1641?
PS: les dates sont en français. Février est février.
Pourquoi une date des années 1600 est-elle possible?
Windows ne stocke pas les horodatages de modification de fichier comme les systèmes Unix le font . Selon le Windows Dev Center (souligné par moi):
Une durée de fichier est une valeur de 64 bits représentant le nombre d'intervalles de 100 nanosecondes écoulés depuis 12h00. 1er janvier 1601 Temps universel coordonné (UTC). Le système enregistre les temps de fichier lorsque les applications créent, accèdent et écrivent dans des fichiers.
Donc, en définissant une mauvaise valeur ici, vous pouvez facilement obtenir les dates des années 1600.
Bien sûr, une autre question importante est: comment cette valeur a-t-elle été définie? Quelle est la date actuelle? Je pense que vous ne pourrez jamais le savoir, car cela aurait pu être simplement une erreur de calcul dans le pilote du système de fichiers. Une autre réponse suppose que la date est en réalité un horodatage Unix interprété comme un horodatage Windows, mais qu'ils sont en fait calculés sur des intervalles différents (secondes par rapport aux nanosecondes).
Comment cela est-il lié au problème de l'année 2038?
L'utilisation d'un type de données 64 bits signifie que Windows (en général) n'est pas affecté par le problème de l'an 2038 des systèmes Unix traditionnels, car Unix utilisait initialement un entier 32 bits, qui déborde plus rapidement que le 64 bit entier que Windows a. (Ceci malgré le système Unix fonctionnant sur secondes et Windows fonctionnant sur micro/nanosecondes.)
Windows est toujours concerné lors de l’utilisation de programmes 32 bits compilés avec les anciennes versions de Visual Studio, bien sûr.
Les systèmes d'exploitation Unix plus récents ont déjà étendu le type de données à 64 bits, évitant ainsi le problème. (En fait, étant donné que les horodatages Unix fonctionnent en quelques secondes, la nouvelle date d'emballage sera dans 292 milliards d'années.)
Quelle est la date maximum pouvant être définie?
Pour les curieux, voici comment calculer cela:
- Les nombre de valeurs possibles dans un entier 64 bits sont 263 - 1 = 9223372036854775807.
- Chaque tick correspond à 100 nanosecondes, soit 0,1 µs ou 0,0000001 s.
- La plage de temps maximale serait 9223372036854775807 ⨉ 0.0000001 s, donc des centaines de milliards de secondes.
- Une heure a 3600 secondes, un jour 86400 secondes et un an 365 jours, donc il y a 86400 365 s = 31536000 sdans une année. Ce n’est bien sûr qu’une moyenne ignorant les années bissextiles , secondes intercalaires ou tout changement de calendrier que les futurs régimes postapocalyptiques pourraient imposer aux terriens restants.
- 9223372036854775807 ⨉ 0.0000001 s/31536000 s ≈ 29247 années
@corsiKaexplique comment soustraire des années bissextiles: 29247/365/4 20- Votre année maximale est donc 1601 + 29247 - 20 = 30828.
Certaines personnes ont en fait, essayé de régler cela et ont présenté la même année.
Si vous ne vous sentez pas trop mal à propos de deviner, laissez-moi vous donner une explication. Et je ne veux pas dire "quelqu'un définit la valeur comme un non-sens", c'est évidemment toujours possible :)
Le temps Unix utilise généralement le nombre de secondes depuis 1970. Windows, en revanche, utilise 1601 comme année de début. Donc, si nous supposons (et c’est une grande hypothèse!) Que le problème est une conversion incorrecte entre les deux temps, nous pouvons imaginer que la date qui était censée être représentée est en réalité au cours de l'année 2011 (1970 + 41), qui a été incorrectement converti en 1640 (1601 + 41). EDIT: En fait, j'ai commis une erreur lors de la première année Windows. Il est possible que la création ait eu lieu en 2010 ou qu’une autre erreur soit en cause (les erreurs off-by-one sont assez courantes dans les logiciels: D).
Étant donné que cette année est une autre des dates de suivi associées au fichier en question, je pense que c'est une explication assez plausible :)
Comme cela a été écrit par d’autres, l’époque Windows est le 1601-01-01 00:00 .
Le nombre de secondes entre cette époque et l’heure du fichier affichée, est 1,266.705.294 .
Si nous ajoutons cela à l'époque Unix, nous arrivons à 2010-02-20 23:34:54 CEST , un samedi. C’est environ un an avant la date du dernier accès, ce qui le rend un peu plausible. Donc, c’était peut-être un timestamp Unix interprété contre la mauvaise époque.
Comme d'habitude pour ce genre de questions, le blog de Raymond Chen a une réponse à ce sujet extrait de "Pourquoi l'époque Win32 du 1er janvier 1601?" entrée du 6 mars 2009:
La structure
FILETIMEenregistre le temps sous forme d'intervalles de 100 nanosecondes depuis le 1er janvier 1601. Pourquoi cette date a-t-elle été choisie?Le calendrier grégorien fonctionne sur un cycle de 400 ans et 1601 est la première année du cycle qui était actif au moment de la conception de Windows NT. En d'autres termes, il a été choisi pour que les calculs soient bien faits.
En fait, le courrier électronique de Dave Cutler le confirme.