TYPO3 Core

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 ...

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

• 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.

thanks for the issue and detailed update. I am closing this issue as duplicate of #77562