Feature #51844
open
Fix date-format in edit-view of a record
0%
Description
If you configure the date-format for the BE to show as "d.m.y" it shows correct in the list-view. But edit-view for a record still has the "d-m-y"-format.
Updated by Mathias Schreiber over 9 years ago
- Category changed from Backend User Interface to FormEngine aka TCEforms
- Target version set to 7.4 (Backend)
Updated by Susanne Moog over 8 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Mathias Schreiber over 8 years ago
- Target version set to Candidate for patchlevel
Updated by
Updated by Jo Hasenau about 8 years ago
- Status changed from New to Accepted
- Assignee set to Jo Hasenau
- TYPO3 Version changed from 7 to 6.2
- PHP Version set to 5.5
This is already broken in 6.2 - so we should fix it in 6, 7 and master.
Updated by Jo Hasenau about 8 years ago
- Status changed from Accepted to Needs Feedback
After taking a look at how the parameters are set and used in several core methods, I think the actual problem IS exactly that global system wide setting of a date format.
IMHO it does not make sense to use that global format for the rendering of date, time and datetime information, when the backend on the other hand offers different locales for the backend users.
As a German user I would expect dd.mm.yy, while the English user might need dd-mm-yy and the US user would like to see mm/dd/yy.
https://en.wikipedia.org/wiki/Date_format_by_country
So the whole concept should be changed to use the default formats of the chosen locale for the backend users, which then could use the global parameter as a fallback.
Maybe even that fallback would not be necessary, since the default would be English anyway.
So we should deprecate that parameter and fix the datetime handling system wide based on backend user locales.
Updated by Jo Hasenau about 8 years ago
Additionally there might be different formats for same language settings. i.e. for English US, English EN - so it seems useful to introduce a selectable date format that can be set within the backend user settings.
Updated by Alexander Opitz almost 8 years ago
- Tracker changed from Bug to Feature
- Status changed from Needs Feedback to Accepted
- Target version changed from Candidate for patchlevel to 8 LTS
Changed to a feature request.
Updated by Riccardo De Contardi about 7 years ago
- Target version changed from 8 LTS to 9.0
Updated by Susanne Moog about 6 years ago
- Related to Epic #77562: Misbehaviors with datetime values and timezones added
Updated by Susanne Moog about 6 years ago
- Target version changed from 9.0 to 9 LTS
Updated by Susanne Moog over 5 years ago
- Target version changed from 9 LTS to Candidate for Major Version
Updated by Benni Mack 10 months ago
I agree it would be good to have a user-specific date format in the future.
However, I think it would be beneficial NOT to use this in editing fields.
Imagine something like: Use the format "Tue, 23.05.2019" for dates (check out the standards here https://unicode-org.github.io/icu/userguide/format_parse/datetime/#producing-normal-date-formats-for-a-locale) but this is not the format you want for editing, but for displaying.