Hola,
Mi Discourse (2.6.0.beta4) está configurado con Europa/París como la zona horaria predeterminada para las fechas locales de Discourse, pero cuando intento seleccionar una hora, la hora mostrada es incorrecta, como se muestra en esta captura de pantalla:
Incluso si escribo “20:00:00”, la hora mostrada es “Hoy, 22:00”. La función moment.tz.guess() ejecutada en mi navegador devuelve “Europe/Paris”, así que no sé realmente qué estoy haciendo mal.
¿Alguna idea?
Gracias,
@j.jaffeux ¿tienes alguna idea de qué podría estar causando esto?
Creo que es un manejo incorrecto de las comillas francesas (bbcode, si recuerdo correctamente). El caso ya se abordó para la localización alemana.
https://meta.discourse.org/t/locale-date-timezone-cooking-error-with-french-localization/161532
Quito las comillas de tz, no es una solución a largo plazo, pero… funciona 
Sí, lo siento, estuve fuera el lunes y martes. No puedo reproducirlo localmente, pero creo que es el mismo caso.
Opté por esta solución:
https://github.com/discourse/discourse/pull/10986
Técnicamente, esto es más un error de texto/markdown que un error de fechas locales. Podríamos querer una solución más global para esto. Aunque solo he recibido quejas sobre esto en el contexto de las fechas locales, supongo que es porque se usa más y es más probable que se edite manualmente.
No creo que esté funcionando. También podría haber algo relacionado con la línea de condición 99 de discourse-local-dates.js.es6:
if (config.timezone && moment.tz.names().includes(config.timezone))
que no es verdadera (pero debería serlo).
edición
Acabo de darme cuenta de que la corrección se comprometió en otra rama. ¡Volveré pronto 
… así que no, lo verifiqué:
[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»]
son correcto, correcto, incorrecto, incorrecto.
Y también, en mi teclado francés azerty, las comillas son realmente ". Ni siquiera sé cómo hacer « o » sin copiar y pegar, lo cual probablemente sea normal 
Ciertamente no reprocho nada “incorrecto”:
Y esto es lo que ocurre: en realidad no escribes tú mismo estas citas; se trata de alguna conversión que está sucediendo.
Es raro, tengo 16h00 para los últimos dos.
Como puedes reproducir el problema, ¿podrías intentar agregar un registro aquí: 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]);
Y mostrarme exactamente qué obtienes.
¡Por supuesto! Pero ahí me perdiste 
Supongo que querrás un registro de Rails, ¿verdad? Realmente no soy un experto, solo un poco entusiasta. ¡Y disculpa! Leí mal un cinco como un seis o no sé qué pasó: el tercero es el único que no funciona, mi culpa. El cuarto no funciona en la vista previa, pero sí en la publicación final 
He enviado otra solicitud de extracción; quizás esperemos a que esto se resuelva antes de que te metas.
Lo que logré ver es que falta el atributo “data-timezone” (cuando algo no funciona)
Mensaje
Actualizar publicación (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
sí, porque no entiende las comillas convertidas, por eso estoy tratando de forzarlas a un estado conocido.
Siento tener que preguntar, te dejaré trabajar después de esto. Tenía la impresión de que el ; de \« era lo que hacía que
&& moment.tz.names().includes(config.timezone) fallara.
¿Podría ser que config.timezone esté escapado en HTML?
No te preocupes, puedo estar completamente equivocado 
Lo que preguntas es básicamente lo que hago, pero no en el momento que esperas; eso también podría funcionar. Por ejemplo, antes de mi corrección, algo como:
[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]
generaba estos atributos en el markdown analizado:
{"date"=>"2020-12-20", "time"=>"15:00:00", "timezone"=>"«Europe/Paris»"}
Lo que hace obvio el problema.
Después de mi corrección, obtenemos:
{"date"=>"2020-12-20", "time"=>"15:00:00", "timezone"=>"Europe/Paris"}
Simplemente creo que no había manejado todos los casos de comillas antes. ¿Probaste con el segundo commit que hice?
Sí…
Pero como el raw no es
[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]
sino que ya es
[date=2020-12-20 time=15:00:00 timezone="Europe/Paris"]
Creo que algo está ocurriendo “más adelante en el proceso” , de hecho no sé dónde. \« y \» se introducen.
¡Ah, sí! Puedo verlo en la vista previa del compositor.
[date=2020-12-15 time=14:00:00 timezone="Europe/Paris"
dá
[date=2020-12-15 time=14:00:00 timezone=« Europe/Paris »
Sí, quizás hay dos problemas, uno en el frontend y otro en el backend, porque la corrección anterior mejoró definitivamente el caso en alemán. Creo que solo puedo aplicar la misma expresión regular en el frontend. Ojalá pudiera reproducir esto
Lo haré mañana.
@Benjamin_D / @j.jaffeux ¿sigue siendo un problema?
Creo que sí, pero voy un poco retrasado, aún estoy en la versión 2.6.0 beta5 
Aunque no he visto ningún commit sobre ese problema desde octubre.