When I create a date with “Insert Date” Button it creates something like
[date=2019-08-20 time=20:00:00 timezone="Europe/Berlin"]
I’m on Timezone Europe/Berlin. But, the html result shows “22:00” instead of “20:00”.
When I change the generated code to:
[date=2019-08-20 time=20:00:00 timezone=Europe/Berlin]
it works like a charm.
Here at meta.discourse.org it works correctly. My forum is at v2.4.0.beta2 +316
Thanks
Let’s try here, I’m in France, but it’s the same TZ
[date=2019-08-20 time=20:00:00 timezone="Europe/Paris"]
2019-08-20T18:00:00Z
[date=2019-08-20 time=20:00:00 timezone=Europe/Paris]
2019-08-20T18:00:00Z
results in
Did you reconfigure your server time/time zone away from UTC?
Yes, as I wrote here it works. I guess it is something in the diff from the version here to mine. I remember that it already worked before a couple of updates I made.
No, it is still UTC.
What’s your browser? It’s not related to your server, but is YOUR computer clock correctly configured?
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.
Can you try this in the console of a browser currently browsing a discourse forum:
moment.tz.guess()
says: "Europe/Berlin"
at my forum as well as at meta.discourse.org
Ok will investigate in the next days, thanks for info.
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?
I still have no repro whatever I try on chrome or firefox. Need to dig more.
I had this issue on Safari, didn’t try chrome/firefox yet.
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
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!
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”
0 voters
It’s weird that the current locale would affect the timezone 
@joffreyjaffeux did you fix this by any chances with your recent fixes?
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.
No I will give it a look tomorrow
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?