Ça doit faire un siècle que je me dis qu’il faut que j’y fasse quelque chose et ça doit faire un siècle que je remets ça à plus tard, évidemment !
Bref, il serait plus élégant d’écrire « jeudi 1er juin 2023 » plutôt que « jeudi 1 juin 2023 »…
Sauf que, sauf qu’il faut qu’on remette à plat la gestion des dates dans Dotclear, où on gère plusieurs références, celle du blog, celle de l’auteur, et où dans une même table on mélange les fuseaux horaires, ou plutôt on stocke des dates et heures UTC — en fait en temps Unix — et d’autres en fonction du fuseau horaire défini pour l’auteur.
Souvent tout se confond — je parle des fuseaux horaires —, mais parfois pas ; c’est le cas par exemple pour les voyageurs qui bloguent pendant leurs tribulations.
Et se greffe à ça des questions du type : si un auteur change de fuseau horaire au cours de la vie du blog, est-ce qu’il faut qu’on adapte l’heure affichée de ses anciens billets en fonction de son nouveau fuseau, ou pas ?
J’aurai pour ma part une préférence pour la conservation et pas pour l’adaptation, ce qui justifie d’ailleurs le fait de stocker la date du billet avec les infos de l’auteur au moment où le billet est publié.
Quid des deux autres dates et heures stockées, celle de la création du billet et celle de la dernière modification, pour l’instant stockées toutes les deux en temps Unix ?
De quoi bien se mettre le cerveau en vrac !
Ça va être un petit chantier pour une des prochaines releases…
1 De Bernard -
Ah les ordinaux… Si on s’en refere qu’aux différences / langues c’est déjà compliqué…. Pis si on rajoute qu’on peut modifier le format des dates va falloir suveiller ausi pasque: c’est pas ça non plus ;-)
Mébon, dans un siècle ça peut encore changer,non ?….
2 De Franck -
Yup, on va surtout moderniser tout ça et utiliser des fonctions modernes de PHP, mais ça va demander un peu de travail pour être bien carrés !
3 De Jean-Christian Denis -
Pour ce qui est des fuseaux horaires, ma préférence qui ne s’adapte pas à dotclear:
Point barre. :)
4 De Franck -
Oui mais non, un billet peut être publié sur un blog parisien (UTC+1 ou UTC+2) quand on est en vacances en Australie (UTC+9 ou UTC+10), et c’est pas le même fuseau horaire ;-)
Ou encore un blog américain partagé par plusieurs utilisateurs sur des fuseaux horaires différents.
Je pense qu’il faut conserver cette nuance.
Pour l’admin c’est un poil plus facile en effet, à la nuance d’affichage des dates et heures des items publiés côté public (date des billets par exemple).
Quoi qu’il en soit il va falloir faire un inventaire exhaustif des contextes et voir comment on s’en sort.
5 De Franck -
En gros les dates stockées dans la base devraient avoir l’indication du fuseau horaire correspondant, à nous ensuite d’adapter en fonction du contexte.
6 De Jean-Crhistian Denis -
non.
Tu te compliques la vie à traduire les fuseaux 10 fois pour rien. Car en te connectant à l’admin tu dis a dotclear de mettre le fuseau horaire de ton profil, et ce même si tu es en vacance de l’autre coté de la terre, non ? ça ne sert à rien de l’enregistrer dans ce fuseau. Alors qu’avec mon truc, lorsque tu enregistres ton billet, il prendra l’heure UTC à laquelle tu l’as enregistré, que tu soit ici ou ailleurs, qu’il fasse jour ou nuit. Puis tu as un blog Fr, l’heure du billet sera celle du fuseau horaire du blog => fr, que tu sois ici ou ailleurs.Car dans tous les cas ton lecteur n’aura pas la traduction vers son fuseau horaire à lui. Sauf si son navigateur fait la traduction pour lui.
J’avais joué avec ça sur une branch pendant quelques mois, et quelques utilisateurs en fuseaux différents, ça me paraissait cohérent.
Ah oui, j’avais viré l’option de mettre un fuseau horaire différent par billet :p
7 De Franck -
Voilà, il faut poser tout ça et définir ce qui nous parait le plus logique et le plus simple/évident pour l’utilisateur/lecteur.
Par ailleurs il faut garder sous le coude qu’on a une rétrocompatibilité à assurer ;-)