Wrong time when using the date picker: bug?

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,

3 Likes

@joffreyjaffeux any ideas on what could be causing this?

2 Likes

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

3 Likes

I strip the tz of its quotation marks, not a long term solution, but… It works😁

2 Likes

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.

4 Likes

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 :sweat_smile:
… 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

1 Like

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 :thinking:

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.

1 Like

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.

1 Like

well of course! but you lost me there :smile: 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 :crazy_face:

1 Like

I have pushed another pull request, maybe let’s wait this before you dig.

2 Likes

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" = 1954
1 Like

yes because it doesn’t understand the converted quotes, this is why I’m trying to force them into a known state.

2 Likes

I’m sorry to even ask, I’ll let you work after that, I was under the impression that it was the ; of the \&laquo; which makes
&& moment.tz.names().includes(config.timezone) fails
Could config.timezone be html escaped ?

1 Like

No worries, I can totally be wrong :smiley:

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?

2 Likes

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” :thinking: , I actually don’t know where . \&laquo; and \&raquo; 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 »

1 Like

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 :sweat_smile:

Will do it tomorrow.

5 Likes

@Benjamin_D / @joffreyjaffeux is it still an issue?

1 Like

I think so, but I’m lagging a bit, I’m still at 2.6.0 beta5 :flushed: I haven’t seen any commit about that issue since October though.