Propose new features
Designing Decidim together
Is your feature request related to a problem? Please describe.
In multinational/multiregional instances, such as Metadecidim, it is sometimes confusing that the system shows the times on the platform in a different timezone than what the user is on. It would be great if we could display the date/time in the user's local time.
Describe the solution you'd like
Everywhere where we show any dates or times, we would display them in the user's own timezone. This information is available through the browser APIs and would not require any additional configuration fields to be added for the user.
Describe alternatives you've considered
Using browser extensions but this is also not possible right now because the dates and times do not contain the timezone information with them.
Additional context
The date and time display and conversion should happen at the user's browser. This would allow the content served by the server to be cached either fully or partially.
If we add the timezone information to the dates and times displayed by the platform, the front-end code could calculate the correct date and time to display for the user and this would not cause any problems with the caching strategies.
This information is possible to provide to the browser using the <time> tag
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/time
Does this issue could impact on users private data?
No, as the calculation happens in the user's browser.
Funded by
No funding available right now.
Report inappropriate content
Is this content inappropriate?
Comment details
You are seeing a single comment
View all comments
Conversation with Ivan Vergés
I think we should do both, we did this for a client in Canada, they have multiple timezones, some of the use VPNs, maybe are in other timezones and they were very clear that they prefered to be able to choose it as automatic tools not always work well for everybody.
But yeah, the timezone issue is something that we are not full aware in Europe as most of us share the same one.
Possibly the user specific setting might make sense some times, such as adjusting some of the recurring tasks, e.g. when the users would receive their notifications. But other than that, I don't see it very useful, from the user interface perspective.
I understand that e.g. in Canada/US people might sometimes want to see the times in their home timezone, e.g. if they live at the east coast but are travelling for few days at the west coast. But even in that case, I wouldn't see it very disturbing for the users if the time changes when they are travelling. After all, they still have control over this from their computer/device settings, in case they want to adjust.
VPN should not generally interfere with the computer's timezone, it should remain the same even when behind a VPN.
I do understand the point, there are some edge cases where it might make sense to implement both. But I think the priority here should be to implement what works the best for most people and make the change in a sustainable way, e.g. in case we want to implement the mentioned caching solutions (that we already have for some of the cells).
Either way, the user-specific setting can be also implemented in a sustainable way from the caching standpoint, i.e. using the user defined timezone in the front-end rather than rendering the content in the correct timezone at the backend. But I think the priority (at least for this proposal) should be the automatic timezone based on the device's settings.
Sure, but this is as easy as have an option in the select, the default:
Show dates in this timezone:
"Detect automatically"
"User organization's timezone (Paris bla bla bla)"
"comprehensive list..."
Loading comments ...