Olá,
Meu Discourse (2.6.0.beta4) está configurado com o fuso horário Europe/Paris como padrão para datas locais, mas ao tentar escolher um horário, o tempo exibido está incorreto, conforme mostrado nesta captura de tela:
Mesmo quando escrevo “20:00:00”, o horário exibido é “Hoje, 22:00”. A função moment.tz.guess() executada no meu navegador retorna “Europe/Paris”, então não consigo identificar onde estou errando.
Alguma ideia?
Obrigado,
@j.jaffeux alguma ideia do que possa estar causando isso?
Acho que é um mau manuseio da aspa francesa (bbcode, se me lembro corretamente). O caso foi abordado para o locale alemão.
https://meta.discourse.org/t/locale-date-timezone-cooking-error-with-french-localization/161532
Eu removo as aspas do tz, não é uma solução de longo prazo, mas… Funciona 
Sim, desculpe, estive ausente na segunda/terça-feira. Não consigo reproduzir localmente, mas acho que é o mesmo caso.
Optei por esta correção:
Tecnicamente, isso é mais um bug relacionado à formatação de texto/markdown do que a datas locais. Talvez seja interessante ter uma solução mais abrangente para isso. Embora eu tenha recebido reclamações sobre isso apenas no contexto de datas locais, imagino que seja porque esse recurso é mais utilizado e mais propenso a ser editado manualmente.
Acho que não está funcionando. Talvez haja também algo relacionado à linha de condição 99 de discourse-local-dates.js.es6
if (config.timezone && moment.tz.names().includes(config.timezone))
que não é verdadeira (mas deveria ser).
edição
Acabei de perceber que a correção foi comprometida em outra branch. Volto em breve 
… então, não, verifiquei:
[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»]
estão corretos, corretos, errados, errados
E também, no meu teclado francês azerty, as aspas são realmente ". Eu nem sei como fazer « ou » sem copiar e colar, o que provavelmente é normal 
Eu certamente não reprovo nada “errado”:
E é isso aí: você não escreve essas citações de verdade; há alguma conversão acontecendo.
É estranho, tenho 16h00 para os últimos dois.
Como você consegue reproduzir o problema, poderia tentar adicionar um log aqui: 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]);
E me mostre exatamente o que você obtém.
Claro que sim! Mas você me perdeu aí 
Acredito que você gostaria de um log do Rails? Eu realmente não sou um especialista, apenas um pouco entusiasta! E desculpe, eu li um cinco como um seis ou não sei, o terceiro só não funciona, minha culpa, o quarto não funciona na pré-visualização mas está certo na postagem final 
Empurrei outro pull request; talvez seja melhor esperar isso antes de você investigar.
O que consegui ver é que o atributo “data-timezone” está faltando (quando algo não funciona)
Mensagem
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
Sim, porque ele não entende as aspas convertidas, é por isso que estou tentando forçá-las para um estado conhecido.
Sinto até por perguntar, mas vou te deixar trabalhar depois disso. Eu tinha a impressão de que era o ; do \« que fazia
&& moment.tz.names().includes(config.timezone) falhar.
Será que o config.timezone está com escape HTML?
Sem problemas, posso estar totalmente errado 
Então, o que você pergunta é basicamente o que eu faço, mas não no momento que você espera; isso também poderia funcionar. Por exemplo, antes da minha correção, algo como:
[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]
Resultaria nestes atributos no markdown analisado:
{"date"=>"2020-12-20", "time"=>"15:00:00", "timezone"=>"«Europe/Paris»"}
O que torna o problema óbvio.
Após minha correção, temos:
{"date"=>"2020-12-20", "time"=>"15:00:00", "timezone"=>"Europe/Paris"}
Acho apenas que não havia tratado todos os casos de aspas antes. Você tentou com o segundo commit que fiz?
Sim…
Mas, como o raw não é
[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]
mas já é
[date=2020-12-20 time=15:00:00 timezone="Europe/Paris"]
acho que algo está acontecendo “mais adiante” , na verdade não sei onde. \« e \» são introduzidos.
Ah, sim! Consigo ver isso na pré-visualização do compositor:
[date=2020-12-15 time=14:00:00 timezone="Europe/Paris"
resulta em
[date=2020-12-15 time=14:00:00 timezone=« Europe/Paris »
Sim, talvez haja dois problemas, um no front-end e outro no back-end, porque a correção anterior melhorou com certeza o caso em alemão. Acredito que posso aplicar a mesma expressão regular no front-end. Gostaria de conseguir reproduzir isso
Vou fazer isso amanhã.
@Benjamin_D / @j.jaffeux, ainda é um problema?
Acho que sim, mas estou um pouco atrasado, ainda estou na versão 2.6.0 beta5 
Não vi nenhum commit sobre esse problema desde outubro, no entanto.