Insert Date Timezone is always UTC ; my Timezone is ignored

hewo7 · August 20, 2019, 5:06pm

No, it is still UTC.

joffreyjaffeux · August 21, 2019, 5:58am

What’s your browser? It’s not related to your server, but is YOUR computer clock correctly configured?

hewo7 · August 21, 2019, 6:52am

I tested Firefox and Chrome/Chromium on Windows, Linux and Android. On each browser it is the same behavior. Oh and my clock is always Europe/Berlin.

joffreyjaffeux · August 21, 2019, 7:27am

Can you try this in the console of a browser currently browsing a discourse forum:

moment.tz.guess()

hewo7 · August 21, 2019, 8:00am

says: "Europe/Berlin"

at my forum as well as at meta.discourse.org

joffreyjaffeux · August 21, 2019, 8:01am

Ok will investigate in the next days, thanks for info.

lorddevil · September 19, 2019, 6:38am

I am having the exact same issue! Without quotes it works like a charm. But the Discourse Editor always creates “Europe/Berlin” instead of Europe/Berlin - and in preview it shows wrong time then. Can this be fixed?

joffreyjaffeux · September 19, 2019, 5:53pm

I still have no repro whatever I try on chrome or firefox. Need to dig more.

lorddevil · October 1, 2019, 5:54am

I had this issue on Safari, didn’t try chrome/firefox yet.

Daniel_Tesla · November 4, 2019, 2:38pm

Any Updates on this Issue?

I have the same behaviour as mentioned above. As soon as I leave out the “” it all works fine. But when I use them the system seems to take the UTC +/- the hours of the timezone my client runs in.

Btw. the same occurs here when I write nonsense in the timezone like:
[date=2019-08-20 time=20:00:00 timezone="nonsense"]
or
[date=2019-08-20 time=20:00:00 timezone=nonsense]
2019-08-20T20:00:00Z

v.stephan · November 15, 2019, 11:17pm

I also state the exact same problem. It more or less seems to be an issue with “German” installations.

Well, fun fact, I tried to reset settings by running domain.de/wizard there I changed the locale to English US and walked through the complete wizard. With English setting I can paste times and they are shown correctly. Well is say for example Tomorrow 11:15 PM (Europe/Berlin) but I really putted 23:15 in German time. So it is displayed correctly.

When I wizard my forum back to “Deutsch” and pasting a new appointment with time … then the + 1 hour effect comes back again. (The times pasted in English setup are still displayed right).

So this does not seem to be a server time thing. Something seems to crash between localization of Europe and UTC.

Happy to test or give more advice if needed.

Running discourse in docker.

THX for further assistance!

v.stephan · November 15, 2019, 11:53pm

Little addition, I realized a ¿small? difference, between my installation and this official one.

We deactivated the “allow user locale” option. So users are not able to change language by themselves. I don not know if this is helpful.

What is about the others that experienced the same problems, namely @Daniel_Tesla @lorddevil, @zogstrip @hewo7 can your users change their interface locale settings. Or in german under Settings › General Settings: allow user locale: “Erlaube Benutzern, ihre eigene Oberflächensprache zu wählen”

allow user locale acitive
allow user locale inactive

0 voters

zogstrip · November 20, 2019, 5:03pm

It’s weird that the current locale would affect the timezone

@joffreyjaffeux did you fix this by any chances with your recent fixes?

v.stephan · November 20, 2019, 5:04pm

I would be happy to give further assistance for tests and debugging if necessary. If some from the team wants to get a closer look into the topic.

joffreyjaffeux · November 20, 2019, 5:06pm

No I will give it a look tomorrow

joffreyjaffeux · November 21, 2019, 10:48am

This should be fixed by:

https://github.com/discourse/discourse/commit/3d1b6b6729eab386f5e7f2c786fd521c37fd8f05

Thanks for info

More context, it seems like that when Discourse instance is set to german locale, we will replace quotes " by german quotes „“ which was breaking our parser.

@gerhard I made a fix directly into local-dates for now, do you think we should try to fix it higher in the chain?

parseBBCodeTag itself before sending the matched string?
in pretty text?

v.stephan · November 21, 2019, 11:03am

Wow that was fast! THX a lot!

May I ask a noob question? As we running our installation in docker, ist this fix merged in master and will be loaded if we just run a update likewise described in How do I manually update Discourse and Docker image to latest?

Thanks for a short answer! And once again thank you so much!

joffreyjaffeux · November 21, 2019, 11:08am

Yes this post has all the info you need. Only thing we need to wait for this commit to be in test-passed branch.

I just checked, it seems to be the case:

https://github.com/discourse/discourse/commits/tests-passed

Also you might have to recook posts.

gerhard · November 21, 2019, 11:25am

Yes, I think we should. This might have an impact on other BBCodes as well. I’m not sure if it’s a bug in markdown-it or somewhere in our code, but it definitely shouldn’t apply smartquotes to BBCode attributes.

system · December 21, 2019, 11:27am

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.