Hi,
My discourse ( 2.6.0.beta4 ) is configured with the Europe/Paris as the discourse local dates default timezones, but when I try to pick a time, the displayed time is wrong, as shown on this screenshot:
Even if I write “20:00:00”, the displayed time is “Today, 22:00”. The moment.tz.guess() executed in my browser gives “Europe/Paris”, so I don’t really guess what I’m doing wrong.
Any idea?
Thanks,
@joffreyjaffeux any ideas on what could be causing this?
I think it’s a bad handling of the french quotation mark (bbcode if I remember correctly) the case was addressed for the German locale
https://meta.discourse.org/t/locale-date-timezone-cooking-error-with-french-localization/161532
I strip the tz of its quotation marks, not a long term solution, but… It works😁
Yes sorry I was away Monday/Tuesday, I can’t repro locally but I think it’s the same case.
I went with this fix:
https://github.com/discourse/discourse/pull/10986
Technically this is more a pretty text/markdown bug than a local dates bug, we might want to have a more global solution to this. Although I have only had complaint of this in the local dates context, I guess it’s because it’s more used and more likely to be hand edited.
I don’t think it’s working, there might also be something about the condition line 99 of discourse-local-dates.js.es6
if (config.timezone && moment.tz.names().includes(config.timezone))
which isn’t true (but should be).
edit
I just realize the fix was committed on another branch, I’ll be back 
… so no I checked,
[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»]
are right, right, wrong, wrong
And also, on my french azerty keyboard, the quotes are actually " I don’t even know how to make « or » without copy/paste, which is probably normal 
I certainly don’t repro anything “wrong”:
And this is the thing, you don’t actually write these quotes yourself, it’s some conversion happening.
It’s weird I have 16h00 for the last two
As you can repro the issue, could you try to add a log here: 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]);
And show me exactly what you get.
well of course! but you lost me there 
I assume you’d like a rails log ? I really not an expert, just a bit enthusiast!
And sorry, I misread a five for a six or I don’t know, the third one only doesn’t work, my bad, the fourth one doesn’t work in the preview but is right in the cooked post 
I have pushed another pull request, maybe let’s wait this before you dig.
What I managed to see is that the attribute “data-timezone” is missing (when something doesn’t work)
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" = 1954yes because it doesn’t understand the converted quotes, this is why I’m trying to force them into a known state.
I’m sorry to even ask, I’ll let you work after that, I was under the impression that it was the ; of the \« which makes
&& moment.tz.names().includes(config.timezone) fails
Could config.timezone be html escaped ?
No worries, I can totally be wrong 
So what you ask is basically what I do but not at the time you expect it, that could work too probably. So for example prior to my fix, something like:
[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]
Would give these attributes in parsed markdown:
{"date"=>"2020-12-20", "time"=>"15:00:00", "timezone"=>"«Europe/Paris»"}
Which makes the issue obvious.
After my fix we get:
{"date"=>"2020-12-20", "time"=>"15:00:00", "timezone"=>"Europe/Paris"}
I just think I didn’t have all the cases of quotes handled before. Did you try with the second commit I made?
yep…
But as the raw is not
[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]
but already
[date=2020-12-20 time=15:00:00 timezone="Europe/Paris"]
I think something is going on “further down the line” 
, I actually don’t know where . \« and \» are introduced.
Ah yes ! I can see it in the composer preview
[date=2020-12-15 time=14:00:00 timezone="Europe/Paris"
gives
[date=2020-12-15 time=14:00:00 timezone=« Europe/Paris »
Yes maybe there are two issues front and back, because the previous fix improved deutsch case for sure, I think I can just apply the same regex frontend, I wish I could repro this
Will do it tomorrow.
@Benjamin_D / @joffreyjaffeux is it still an issue?
I think so, but I’m lagging a bit, I’m still at 2.6.0 beta5 
I haven’t seen any commit about that issue since October though.