-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Affichage des dates inférieure à 1970 erroné #47
Comments
Voir le commentaire de @VonC sur https://stackoverflow.com/a/24977895 Il faut modifier le commit manuellement et la bonne date sera enregistrée dans le dépôt. Toutefois git utilise généralement un format non signé |
ah oui, c'est pas du petit fix ! |
@fgallaire c'est du au fonctionnement des timestamp. IMHO le problème sera le même quelque soit le VCS. |
@promethe42 j'ai beaucoup bossé sur ce problème, il y a trois limitations : une liée au type de donnée utilisé pour stocker la date (le J'ai étendu le support de mercurial du 1er janvier 1970 au 13 décembre 1901 : |
@fgallaire merci pour l'info 👍 Cependant, j'ai du mal à imaginer que les corrections en questions ne trouvent pas preneur sur Git. |
@promethe42 Bah le problème c'est que c'est plus dur de contribuer à un logiciel utilisant des technos de merde... Grâce à python et son typage dynamique, pour hg et bazaar il n'y avait en gros qu'à corriger les fonctions liées au timestamp dans un fichier ou deux. Avec Git c'est une autre histoire, il faut modifier le Donc déjà arriver à faire tout ça correctement sans rien oublier faut y aller. Une fois que c'est fait reste à réécrire complètement tous les algos du fichier Une fois que c'est fait faut réussir à faire passer upstream un patch pareil en risquant de casser Git. Je soupçonne que ce patch ne se fera que le jour où Linus aura besoin d'une date antérieure à l'Epoch, et je ne suis pas sûr que cela arrive un jour. |
En plus des dates dans le passé, il y a la date 2222-02-22 qui est utilisée pour la valeur "date future indéterminée" qui n’est pas non plus bien enregistrée. Pour Archéo Lex, dans l’immédiat, ça serait peut-être plus simple de contourner le problème au niveau de l’affichage (quitte à ce que ça soit faux dans le stockage Git), en utilisant le commentaire qui contient, lui, la bonne date. |
@fgallaire @Seb35 D'après ce qu'on m'a dit, Git n'a aucun problème avec le type de données pour stocker les dates. Mais ceux sont les clients - comme GitHub - qui interprètent mal les dates inférieures à 1/1/1970. |
J’ai testé le lien donné par @hashar (hello ! :), les commits avec un timestamp négatif ou supérieurs à l’année 2099 semblent bien enregistrés effectivement (avec ma version de git CLI 2.1.4), et l’affichage est correct pour les années > 2099 mais reste bloqué à 1970 pour les timestamps négatifs (et il semble que git CLI ne gère pas non plus le 1er janvier 1970 00:00:00 +01:00, probablement car le timestamp est négatif à -3600). Données de test :
Comme roadmap, je propose ;
|
@promethe42 La question venant de toi m'étonne, tu te bases sur des on-dit venant de on ne sait qui (ça ne devait pas être Linus...) alors que tu es un très bon développeur et que donc :
Par ailleurs en jetant un nouveau coup d’œil, la situation a pas mal évolué (git/git@b15667b) depuis mes expérimentations sur git et ce que je vous ai raconté n'est plus totalement exact. Les dates utilisent maintenant le type
|
Tu n'as pas fait preuve de beaucoup d'objectivité en disant que git était "un logiciel utilisant des technos de merde". La condescendance ne fera pas avancer le sujet.
Avec quelle version de git ? quelle plateforme/archi ? C'est beaucoup plus compliqué que ça, cf https://stackoverflow.com/a/24977895 (note que j'aurais pu écrire "il te suffit de faire une recherche Google ou dans la ML git") Le "on dit" vient de Emmanuel Raviart avec qui on en a discuté, et qui a creusé le sujet lorsqu'il avait fait un programme pour générer directement des archives Git. En l'occurrence, il ne s'agit pas il me semble de changer le type utilisé pour stocker les dates, mais simplement d'utiliser des valeus négatives, qui sont correctement stockées dans Git (comme l'explique le post ci-dessus) et affichées correctement dans certains clients. |
La dernière
La tienne, Git est censé marcher partout non ? chez toi c'est un bon début
Si c'est la CLI de git qui doit être fixée, c'est bien que le problème ne vient pas de Github ou des autres clients.
Il me semble que mes posts sont assez argumentés mais bon :
Bon c'était pour expliquer pourquoi ça ne gérait pas les dates loin dans le futur. Mais ça s'applique encore pour les dates avant 1970.
Faux, le type utilisé est J'arrêterai sur ce sujet, ça à l'air de froisser les gens que Git ne fonctionne pas bien... |
Comme "tu es un bon développeur", je ne doute pas que tu aies lu mon post et les liens associés - ou même le lien que tu as toi même fourni - qui expliquent clairement que ces considérations dépendent de la plateforme et de la version de Git. Donc comme "tu es un bon développeur", tu sais que tester avec mon git dans mon environnement n'aura pas plus de valeur que "on m'a dit". Comme "tu es un bon développeur", tu sais aussi que pour avancer des affirmations aussi extraordinaires que "[le C] est une techno de merde", il faut des preuves en béton.
Justement. Non.
Dans le post que je mentionne (https://stackoverflow.com/a/24977895) :
Donc contrairement à ce que tu prétends, la gestion des dates :
Tu ne sais manifestement pas ce qu'implique Les contenus que je mentionne explique très clairement pourquoi ton interprétation du problème n'est pas la bonne. Notamment la partie sur les casts.
Ca "froisse" surtout les gens que tu sois condescendant alors que tu ne lis manifestement pas les posts des autres. Ca froisse aussi les gens quand tu les prends de haut en étant intransigeant sur un manque de rigueur dont tu fais toi cruellement défaut (cf "chez toi c'est un bon début"). Tout ce post n'ajoute aucune information au débat, mais tu me contraints à tout répéter par ce que mon post précédent n'a manifestement pas été lu. Voilà à quoi on en arrive... |
Hum... je ne vais pas effectivement me répéter non plus, mes posts sont argumentés avec du code source, tout le monde peut constater que Git ne marche pas, que le code source ne gère pas les dates négatives, etc. Il me semble que donner des liens vers le code source fait montre d'une plus grande rigueur d'argumentation que toi qui argumentais avec des on-dit et des recherches sur Google. Tu craques complètement sur ce sujet j'arrête les frais. |
Tes posts montrent que ton interprétation est naïve au mieux, erronnée au pire.
Donc d'après tes propres références :
As-tu un exemple qui prouve le contraire ?
D'après ce post, tout le monde constate l'inverse, à savoir :
As-tu un exemple qui prouve le contraire ? |
Ce qui est drôle c'est que le "client" que tu appelles git-cli n'existe pas, il y a juste un dépôt qui s'appelle git, et tout le code dans ce dépôt est incapable de gérer les dates négatives... et on s'en rend compte en utilisant Git... Si il n'y a a aucun problème et que tout marche on pourrait juste arrêter d'en parler... Si j'ai le temps j'essayerai de fixer git qui marche déjà parfaitement... |
Pour pallier à l’état de fait que les dates pré-1970 et post-2100 apparaissent actuellement avec des dates "aléatoires", ces dates sont désormais détectées et sont ramenées à des dates aux limites possibles. Pour 1970, la première date acceptée est le 2 janvier 1970 (car le 1er janvier 1970 minuit CET n’est pas représentable, le binaire Git officiel inscrit d’ailleurs l’entier signé (négatif) -3600 sur 64 bits (= 18446744073709548016 vu en entier signé sur 64 bits), ce qui fait buguer certaines interfaces comme gitlist sur archeo-lex.fr). Les années avant 1970 étaient remplacées par des dates plus ou moins aléatoires. Ces dates sont remplacées par le 1er janvier 1970 à 12:00:00 CET. Pour 2100, la limite à 32 bits correspond à l’année 2105 et le binaire Git interdit à partir de 2100. Il y a (sauf erreur dans la base LEGI) que la date 2222-02-22 qui est valide (date d’entrée en vigueur future non-déterminée). Ces dates sont remplacées par le 1er janvier 2099 à 12:00:00 CET. Noter que dans tous les cas la date réelle est inscrite dans le message de commit en français. Ces limitations sont désormais détectées au cours de l’exécution d’Archéo Lex et sont affichées lors de l’enregistrement de la version ainsi qu’à la fin de l’exécution. Une option pour forcer le stockage des dates réelles sera créée. Issue: #47
Du côté d’Archéo Lex, pour Git, c’est en passe d’être résolu avec une version dégradée mais compatible par défaut, celle que je viens de poucher, et des flags pour activer les dates pré-1970 et/ou post-2100, que je viens d’implémenter dans Archéo Lex – je nettoie le code et ça arrive. Dans la version dégradée, les dates pré-2-janvier-1970 sont fixées au 1er janvier 1970 12:00:00 CET (pour éviter les dates "aléatoires" actuelles), et les dates post-2100 sont fixées au 1er janvier 2099 12:00:00 CET (normalement il n’y a que la date 2222-02-02). Bien sûr c’est pas extraordinaire pour les dates pré-1970 mais c’est un moindre mal. Dans la version "vrais dates" à venir, j’ai donc utilisé Depuis hier, j’ai pas mal amélioré le site officiel archeo-lex.fr (basé le gitlist) – c’est dans le chemin /dev/, je ne le marque pas en lien pour éviter que ça soit crawlé – et modulo une petite adaptation de gitlist, qui utilise gitter qui utilise le binaire git, ça fonctionne avec les dates pré-1970 et bien sûr post-2100 (en modifiant l’appel avec un Merci à tous pour la recherche documentaire. Ça résoud pas les difficultés dans Git mais ça pourra donner des exemples pour tester le fonctionnement de tel ou tel client Git. En tous cas, avec un entier signé sur 64 bits, ça couvre ± 292x10^9 années, il faut juste pas qu’il y ait eu une loi le 30 février 1712. |
Un détail aussi, Git enregistre le fuseau horaire et Archéo Lex s’appuie sur pytz pour cela, avec le fuseau horaire de Paris (CET/CEST). Pour le code civil, créé en 1803, j’ai eu la surprise de voir que pytz inscrivait le fuseau horaire |
Avant 1970 et après 2100, les dates sont forcées directement dans le format de stockage Git en passant par `git hash-object`. Cela est activé par deux flags. Ceux-ci peuvent rendre les dépôts créés incompatibles avec certaines plateformes ou logiciels : - le pré-1970 entraîne des timestamps négatifs, - le post-2100 correspond à un entier de plus de 32 bits. Issue: #47
C’est implémenté et déployé en prod sur https://archeo-lex.fr depuis longtemps, c’est donc résolu côté Archéo Lex. Les dépôts créés sont refusés par GitHub et Gitlab, il n’est pas possible de les pousser (remote: error: object 0b8d258877dc76f794974fe10c8763e5662f769e: badDateOverflow: invalid author/committer line - date causes integer overflow). Lors de la création des dépôts par AL, par défaut la version dégradée est créée (cf ci-dessus), et il faut explicitement indiquer les flags |
Par exemple, sur cette page: https://archeo-lex.fr/codes/code-de-l%E2%80%99artisanat
Les commits eux aussi ont la mauvaise date:
La solution à l'air d'être d'utiliser un autre format que le timestamp pour spécifier la date: https://stackoverflow.com/questions/19742345/what-is-the-format-for-date-parameter-of-git-commit
Du coup, a cette ligne, en théorie il faudrait faire:
Par contre, pas moyen de faire fonctionner cette solution. Du coup soit changer l'affichage des dates, soit regler les dates dans git.
The text was updated successfully, but these errors were encountered: