[framacalc] format date interprété bizarrement

J’ai une cellule contenant une date champ qui est interprété bizarrement : https://framacalc.org/testdate

Comportement constaté :

  • 12/6/1980 s’affiche 06-Dec-1980 (ou 12/6/1980 si je précise le format JJ/MM/AAAA)
  • 23/08/1950 s’affiche 10-Nov-1951mais 10/11/1951 si je précise le format JJ/MM/AAAA

Comportement attendu :

  • le format JJ/MM/AAAA devrait afficher 23/08/1950
  • le format JJ-mois-AAAA devrait afficher respectivement 12-Jan-1980 et 23-Aug-1950

Solution proposée :
Je me demande si le commit de février 2020 https://github.com/audreyt/ethercalc/commit/ca81358792d17d04521efe9c820a7123909bdf37 ne corrigerait pas ça.

Je ne trouve pas la version de framacalc, mais ça vaudrait sans doute le coup de vérifier. Quelqu’un a les droits pour regarder ?

Salut,

Tout d’abord, ceci n’est que sujet à mes interprétations, je peux me tromper et je ne suis pas allé dans les tréfonds du code de Framacalc.

La valeur de la date vient-elle initialement d’un copier/coller ? Car je me demande si ce n’est pas dû à cela.

Avec les dates, c’est toujours un problème quand nous les importons. Cela dépend de la valeur de départ (si c’est un nombre ou du texte) et de leur interprétation en fonction du format interne de l’application (ou du langage de programmation utilisé).

En effet, les anglophones (en tout cas le système américain), précise le mois avant le jour, alors que (la plupart des ?) les pays européens le place après.

En d’autre mots: 12/6/1980 peut être vu comme le 6 décembre 1980 aux USA, tandis que ce sera compris 12 juin 1980 en France.

De même que pour 23/08/1950, ce sera le 23 août 1950 en Belgique et le 8 …euh ? Il n’y a pas 23 mois en Amérique… Ah ben alors, ce serait le 8 janvier 1950 + 23 mois => 8 octobre 1951… (m’enfin, ici, c’est le 10 octobre 1951, il y a peut-être une autre subtilité dans le calcul de la conversion texte/nombre)

Donc pour moi, si on insère une date sous la forme de texte, cela va être par défaut la formulation américaine qui sera utilisée. Sauf, si on précise à l’avance le format de la date dans la cellule.

Nous pouvons préciser que cela n’est pas nécessaire lorsque la date est fournie sous un format numérique. Enfin, la règle est différente. Il me semble que, sous cette forme, la valeur correspondrait au nombre de jours écoulés depuis le 30 décembre 1989. Pour être précis c’est le nombre entier de la valeur qui sera le nombre de jours, le nombre décimal sera le temps écoulé en secondes (millisecondes ?) sur la journée. (Et encore, c’est également sujet à problème si on passe d’une base temporelle à une autre…)

Finalement, les essais que nous faisons reposent avant tout sur la base/forme de la valeur initiale. Si c’est un nombre, il est pris tel quel et transposer sans conversion. Si c’est du texte, le logiciel va tenter de le traduire en fonction du format de la cellule si celui-ci y est appliqué, ou selon son sa « localisation » interne. Cette traduction se finalisera sur la forme d’un nombre. Ce nombre sera donc soit issu d’une date reconnue dans sa forme américaine ou européenne. C’est ce nombre qui définit la date aucun autre, dès lors, si on change le format d’affichage de la date, c’est en fonction de ce nombre et pas de la valeur affichée.

Personnellement, je préférerais que le logiciel me donne une erreur de conversion ou un avertissement, voir au mieux me demander quelque est la signification des termes rencontrés.

Finalement, je me dis: Ah, la datation ! Encore un système organisationnel humain !

Merci de ta réponse @PaliPalo

Non, la date a été entrée à la main.
Je suis sensibilisé aux formats de dates, et j’ai effectivement fait des tests en inversant jour et mois, mais ça ne résoud pas le souci.

J’avais remonté il y a qlq années un souci de format, et @arnaudlecam avait signalé au passage qu’il avait intégré le format de date français. Toutefois, comme une correction a été faite depuis, je suppose que le format de date français est bien prévu, mais qu’il s’agit sans doute d’une erreur qui a été corrigée plutôt qu’une impossibilité de gérer les dates en français (en plus, le format de date états-unien est… incohérent).

Je ne connaissais pas cette historique :slight_smile:

Bref, tu as peut-être raison, ce pourrait être un soucis de mise-à-jour.

Au fait, je trouve même le format jour/mois/année incohérent, pas pratique. Le format qui me convient le mieux c’est Année/mois/jour. D’après mes expériences, c’est le format le plus pratique pour le tri en informatique.

Je précise l’incohérence à mon sens : MM/JJ/AAAA est incohérent car les ordres de grandeur ne sont pas présentés de manière croissante (ce devrait être JJ/MM/AAAA puisque JJ < MM < AAAA).

Dans un format texte un format tel que ISO ou raccourci (tel que AAAA-MM-JJ) permet un classement par ordre alphabétique, ce qui est pratique.

Dès lors qu’on définit un type date, une méthode de classement peut et devrait être proposée en même temps pour le gérer (un peu comme une méthode accompagne une propriété dans une classe en langage objet). Ça ne me gêne donc pas que ce format puisse être utilisé.
Note d’ailleurs que le format AAAA-MM-JJ est aussi proposé dans ethercalc ce qui permet. :slight_smile:

D’accord.

Mais bon, finalement, faut-il une régression d’Ethercalc ou non ?! :slight_smile: