#4337
Deprecate user timezones
PLIP (Plone Improvement Proposal)
Responsible Persons
Proposer:
Seconder:
Abstract
While reviewing plone/volto#8304 I recognized that it uses the Web API Intl to get the client OS timezone rather than defaulting to plone.app.event.base.default_timezone via the rest api - which does not even have support for that.
Actually that makes a lot of sense. While we could argue that we should respect the portal timezone always, the user's timezone setting in @@personal-preferences can nowadays be seen as obsolete.
Back then when plone.app.event was created, it was a necessity. The Intl API wasn't available - we could only bet on a timezone based on some request characteristics. Also, smart phones and laptops were not that common, so people on the go did use another persons computer more often (I'm actually thinking of internet cafes which were a window to the world back in late 2000's).
We always had support for the user timezone via plone.app.event.base.default_timezone. But I'm arguing that this is obsolete and should be dropped without a replacement. We actually always had incomplete support for a timezone UI, so it was inconsistently exposed in the editing and viewing UIs. Support for a timezone selection in event editing was gone since Plone 6 and only available in Plone 5 if it was properly configured (TODO: add reference).
Adding full support for the timezone setting in @@personal-preferences would need work in plone.restapi and Volto just for backwards compatibility of a inconsistently exposed obsolete setting.
Blicca/Classic UI isn't as much as a problem as it was always using the default_timezone.
My suggestion is to completly drop support for the timezone setting in @@personal-preferences.
TBC
Ref: default_timezone: https://github.com/plone/plone.app.event/blob/011f9249842ced726220c1592597c0733d7e6021/src/plone/app/event/base.py#L431-L473
Motivation
Assumptions
Proposal & Implementation
Deliverables
Risks
Participants
#4337
Deprecate user timezones
PLIP (Plone Improvement Proposal)
Responsible Persons
Proposer:
Seconder:
Abstract
While reviewing plone/volto#8304 I recognized that it uses the Web API
Intlto get the client OS timezone rather than defaulting toplone.app.event.base.default_timezonevia the rest api - which does not even have support for that.Actually that makes a lot of sense. While we could argue that we should respect the portal timezone always, the user's timezone setting in
@@personal-preferencescan nowadays be seen as obsolete.Back then when plone.app.event was created, it was a necessity. The
IntlAPI wasn't available - we could only bet on a timezone based on some request characteristics. Also, smart phones and laptops were not that common, so people on the go did use another persons computer more often (I'm actually thinking of internet cafes which were a window to the world back in late 2000's).We always had support for the user timezone via
plone.app.event.base.default_timezone. But I'm arguing that this is obsolete and should be dropped without a replacement. We actually always had incomplete support for a timezone UI, so it was inconsistently exposed in the editing and viewing UIs. Support for a timezone selection in event editing was gone since Plone 6 and only available in Plone 5 if it was properly configured (TODO: add reference).Adding full support for the timezone setting in
@@personal-preferenceswould need work in plone.restapi and Volto just for backwards compatibility of a inconsistently exposed obsolete setting.Blicca/Classic UI isn't as much as a problem as it was always using the
default_timezone.My suggestion is to completly drop support for the timezone setting in
@@personal-preferences.TBC
Ref: default_timezone: https://github.com/plone/plone.app.event/blob/011f9249842ced726220c1592597c0733d7e6021/src/plone/app/event/base.py#L431-L473
Motivation
Assumptions
Proposal & Implementation
Deliverables
Risks
Participants