Bug #102087
closedBackend user need a own timezone
0%
Description
Hi,
I am facing the following dilemma: The BE user records a time (not a date time) in his data model. For example, the recurring event always starts at 5pm.
An integer is stored in the database, which is based on the UTC timezone and this is independent of the "phpTimezone" configured in TYPO3.
IMHO: should always be calculated back to UTC. If the BE-user enters 19h and the phpTimeZone is Berlin, then 17h should be stored. That the system is in Berlin and the editor wants to enter a Berlin time,
Then also the date.format-ViewHelper would work correctly.
Maybe this should be changed in the future versions.
Best regards
Clemens
Updated by Christian Kuhn 11 months ago
Yes.
This is a long standing issue in the backend: Users can not have times/dates displayed in "their" selected time zone, there isn't even a selecor for this in the user settings.
The reason this was never fully tackled yet: This is a relatively complex task to finally fully implement:
- First, we must be very sure all date/time fields are always stored in UTC in DB. This may also mean that we change some of the management fields like the scheduler time selection from timestamp to a proper date field (which needs upgrade wizards). We may keep "starttime" and "endtime" for now (those will be even more work), though. Still, in the end, we should essentially always have UTC date fields, and abandon "int" timestamps.
- Next we need a selector in the BE user settings for users to select a timezone. That itself should be relatively easy. Question is, where to get this list from, so we may want to extend the 'locale' class structure that currently delivers 'countries' already for this.
- Then we need to prepare core usages to honor the selected be-user timezone. This will have impact on view helpers, plus we need to make the date/time js selectors aware of this, so a user can use the js selector in his time zone, but the value stored in DB is still changed to UTC.
- We may need various side or preparation patches. For instance, there is a TS setting "clearCacheAtMidnight" ... well, when is midnight?
I'd love to see anyone working in this area ...
Updated by C. Gogolin 10 months ago
Good morning Christian,
Thank you for your detailed answer.
I have worked in the core business of an ERP software vendor for 10 years and know how to deal with time zones and their pitfalls. Currently, as a software developer, I am converting an outdated software to a new platform. Based on my experience, the conversion process would be a bit different:
- Convert time from one time zone to another
- calculate time differences (taking into account time zones)
- uniform formatting and parsing of times
Even if the API only consists of many convenience functions, a unified API or a clear statement represents how you want it to be later.
This API can, then already extension developers use and one would have feedback.
2. Second step extend the persistence layer based on our API (without changing anything!!). These new fields always consist of two fields time zone and time information. This must be clearly mappable in the TCA data model descriptions.
Addition: Cool, it would be also if by injection beside the raw data also equal the formatted time into the model class could be brought. That would be easier for many and the proliferation of how something is formatted would be reduced.
3. Step three: Then I would build BE fields that have timezone+time.
4. Step four is then simple: The BE fields get the possibility to use the timezone of another field. So you can create multiple timezone-dependent BE fields that all refer to one timezone. (first the time zone must be stored in the own table, later other sources are added: e.g. the settings of the FE user or BE user).
All these steps drag on over several release changes. The old time specifications are several releases already marked as deprecated.
5. So in the fifth and final step you can change everything over to the new infrastructure piece by piece.
Best regards
Note on some issues:- the midnight problem: I would do this analogously to the scheduler service: There you can select a user to run the services and this user could have a timezone.
- What time zone there is? This gives us php: https://www.php.net/manual/en/datetimezone.listidentifiers.php
More complex are the formattings: but these can be easily obtained via a free OS (linux) and provided via translation tables.
Updated by Georg Ringer 2 months ago
- Related to Feature #61110: Support for timezones in all date fields in TYPO3 BE added
Updated by Georg Ringer 2 months ago
- Related to Bug #92391: DateTime property has wrong TimeZone in Backend List view added
Updated by Georg Ringer 2 months ago
- Is duplicate of Epic #77562: Misbehaviors with datetime values and timezones added
Updated by Georg Ringer 2 months ago
thanks for the issue and detailed update. I am closing this issue as duplicate of #77562