Bonjour,
Mon Discourse (2.6.0.beta4) est configuré avec Europe/Paris comme fuseau horaire par défaut pour les dates locales, mais lorsque j’essaie de sélectionner une heure, l’heure affichée est incorrecte, comme le montre cette capture d’écran :
Même si je saisis “20:00:00”, l’heure affichée est “Aujourd’hui, 22:00”. La fonction moment.tz.guess() exécutée dans mon navigateur renvoie “Europe/Paris”, donc je ne vois pas vraiment ce que je fais de mal.
Une idée ?
Merci,
@j.jaffeux As-tu des idées sur ce qui pourrait en être la cause ?
Je pense qu’il s’agit d’une mauvaise gestion des guillemets français (bbcode si je me souviens bien). Le cas a été traité pour la locale allemande.
https://meta.discourse.org/t/locale-date-timezone-cooking-error-with-french-localization/161532
Je retire les guillemets de tz, ce n’est pas une solution à long terme, mais… Ça marche 
Oui, désolé, j’étais absent lundi/mardi. Je n’arrive pas à reproduire le problème localement, mais je pense qu’il s’agit du même cas.
J’ai opté pour cette correction :
https://github.com/discourse/discourse/pull/10986
Techniquement, il s’agit davantage d’un bug lié à l’affichage du texte ou du Markdown que d’un problème de dates locales. Nous pourrions envisager une solution plus globale. Bien que je n’aie reçu des plaintes à ce sujet que dans le contexte des dates locales, je suppose que c’est parce que cette fonctionnalité est plus utilisée et plus susceptible d’être modifiée manuellement.
Je ne pense pas que cela fonctionne, il pourrait aussi y avoir un problème avec la ligne de condition 99 de discourse-local-dates.js.es6
if (config.timezone && moment.tz.names().includes(config.timezone))
qui n’est pas vraie (mais devrait l’être).
edit
Je viens de réaliser que la correction a été commitée sur une autre branche, je reviens 
… donc non, j’ai vérifié,
[date=2020-12-20 time=15:00:00 timezone=„Europe/Paris“]
[date=2020-12-20 time=15:00:00 timezone=Europe/Paris]
[date=2020-12-20 time=15:00:00 timezone="Europe/Paris"]
[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]
sont correct, correct, incorrect, incorrect
Et aussi, sur mon clavier français AZERTY, les guillemets sont en fait ". Je ne sais même pas comment faire « ou » sans copier/coller, ce qui est probablement normal 
Je ne reproche certainement rien de « faux » :
Et c’est là le point : vous ne rédigez pas vous-même ces citations, il s’agit d’une conversion automatique.
C’est étrange, j’ai 16h00 pour les deux derniers.
Comme vous pouvez reproduire le problème, pourriez-vous essayer d’ajouter un journal ici : https://github.com/discourse/discourse/blob/master/plugins/discourse-local-dates/assets/javascripts/lib/discourse-markdown/discourse-local-dates.js.es6#L15
console.log(matches[1]);
Et montrez-moi exactement ce que vous obtenez.
Bien sûr ! Mais là, tu m’as perdu 
Je suppose que tu aimerais un journal Rails ? Je ne suis vraiment pas expert, juste un peu passionné !
Et désolé, j’ai lu un cinq comme un six ou je ne sais quoi, seul le troisième ne fonctionne pas, c’est de ma faute, le quatrième ne fonctionne pas en aperçu mais il est correct dans le message final 
J’ai soumis une autre demande de tirage. Peut-être devrions-nous attendre cela avant que tu ne creuses.
Ce que j’ai pu constater, c’est que l’attribut « data-timezone » est manquant (lorsque quelque chose ne fonctionne pas)
Message
Post Update (1.1ms) UPDATE "posts" SET "raw" = '[date=2020-12-20 time=12:00:00 timezone=Europe/Paris]
[date=2020-12-20 time=12:00:00 timezone="Europe/Paris"]', "self_edits" = 3, "cooked" = '<p><span data-date="2020-12-20" data-time="12:00:00" class="discourse-local-date" data-timezone="Europe/Paris" data-email-preview="2020-12-20T11:00:00Z UTC">2020-12-20T11:00:00Z</span><br>
<span data-date="2020-12-20" data-time="12:00:00" class="discourse-local-date" data-email-preview="2020-12-20T12:00:00Z UTC">2020-12-20T12:00:00Z</span></p>', "baked_at" = '2020-10-21 15:25:53.050518', "updated_at" = '2020-10-21 15:25:53.050721' WHERE "posts"."id" = 1954
Oui, car cela ne comprend pas les guillemets convertis, c’est pourquoi j’essaie de les forcer vers un état connu.
Désolé de poser la question, je te laisse travailler après cela. J’avais l’impression que c’était le ; de \« qui faisait échouer
&& moment.tz.names().includes(config.timezone)
Est-ce que config.timezone pourrait être échappé en HTML ?
Pas de souci, je peux tout à fait me tromper 
Donc, ce que tu demandes, c’est essentiellement ce que je fais, mais pas au moment où tu t’y attends ; cela pourrait probablement fonctionner aussi. Par exemple, avant ma correction, quelque chose comme :
[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]
produisait ces attributs dans le Markdown analysé :
{"date"=>"2020-12-20", "time"=>"15:00:00", "timezone"=>"«Europe/Paris»"}
Ce qui rend le problème évident.
Après ma correction, nous obtenons :
{"date"=>"2020-12-20", "time"=>"15:00:00", "timezone"=>"Europe/Paris"}
Je pense simplement que je n’avais pas pris en compte tous les cas de guillemets auparavant. As-tu essayé avec le deuxième commit que j’ai fait ?
Oui…
Mais comme le raw n’est pas
[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]
mais déjà
[date=2020-12-20 time=15:00:00 timezone="Europe/Paris"]
Je pense que quelque chose se passe « plus loin dans la chaîne » , je ne sais pas vraiment où. \« et \» sont introduits.
Ah oui ! Je peux le voir dans l’aperçu du compositeur
[date=2020-12-15 time=14:00:00 timezone="Europe/Paris"
donne
[date=2020-12-15 time=14:00:00 timezone=« Europe/Paris »
Oui, il y a peut-être deux problèmes, côté front et côté back, car la correction précédente a certainement amélioré le cas allemand. Je pense que je peux simplement appliquer la même expression régulière côté front. J’aimerais pouvoir reproduire ce problème
Je le ferai demain.
@Benjamin_D / @j.jaffeux est-ce que c’est toujours un problème ?
Je le pense, mais je suis un peu en retard, je suis toujours sur la version 2.6.0 beta5 
Cependant, je n’ai vu aucun commit concernant ce problème depuis octobre.