Closed StevenDufresne closed 11 months ago
Ah, yeah, I missed that that was a side effect of https://github.com/WordPress/wordcamp.org/pull/1133. We could copy/paste the code from the map block that converts it to the local timezone, or maybe import
it etc.
There might be edge case issues on the upcoming events page regarding the monthly categorization, as the current grouping of events is based on server time. So when the client side displays the local time, there could be cases like - an event at UTC time 11/30 12:00pm would be categorized in November, but in a +13 timezone, it would be 12/1 01:00am and should technically fall under December.
Are we able to get a user's locale information?
That's a really good point. It looks like we used to use JS to render the list, and switched to the server in https://github.com/WordPress/wordcamp.org/pull/1127/files#diff-3f6f89e39631e71571a5cac7df4214781c4811d4a3ddc790132c63df3d13aa5b. What was the reason for that, instead of doing the grouping in JS?
I wonder if it's better to switch back to the JS code, and port the grouping to it?
Are we able to get a user's locale information?
We can get the locale information but it won't reliably tell you the timezone. We'll need JavaScript.
It looks like we used to use JS to render the list
The intention was to use the Time
wporg-mu-plugins block (i opened this PR), but I don't think we'll be able to use it. I'll restore the front end code.
I wonder if it's better to switch back to the JS code, and port the grouping to it?
I think so.
We currently display times to users using UTC. It is more user-friendly to use the user's timezone.
Screenshots