Unify date formatting, base it on locale#1509
Conversation
|
Use Run test server using develop.opencast.org as backend: Specify a different backend like stable.opencast.org: It may take a few seconds for the interface to spin up. |
|
This pull request is deployed at test.admin-interface.opencast.org/1509/2026-02-19_14-58-50/ . |
|
This pull request has conflicts ☹ |
This patch aims for a consistent date display across the entire ui. That it is not always consistent can be seen for example in the event details metadata, where the start date is formatted differently from the created date. Furthermore, this patch aims to base date formatting more on the chosen locale to create a more intuitive experience for users. No more A.M./P.M. in the german locale for example. To achieve this, date-fns is chosen as the gold standard and momentjs is removed from the project completely. Not only because moment is legacy, but also because our datepickers were using date-fns already and will not use anything else. Additionally, this removes our custom date formatting from the translation files and replaces it with date-fns tokens. In my opinion, we do not need to try and be smarter than our datetime library when it comes to formatting dates. Translators retain the ability to enforce their favourite formatting should they so chose, but will have to be aware that it will not be respect everywhere, e.g. not in the datepickers. This patch contains changes to all translation files. I am aware that everything except en_US will get overwritten, the changes to other languages are merely for ease of reviewing. If this patch is merged, the translations should be adapted asap as per this example.
Arnei
force-pushed
the
date-display-unification
branch
from
faa421c to
3075b0a
Compare
There is an inconsistency when English UK is selected. |
|
Thanks for testing! Interesting, I'm not seeing that for UK on my end. 
Could you try clearing the cache for the website, just in case? |
Indeed, interesting.
Details Firefox: |
|
we noticed this when selecting UK English and still getting the (questionable :P) US date format. thx for fixing |
|
As far as I can tell, the issue marcusm7 discovered is a problem with react-datepicker. When setting the datepicker to use an input field for the time selection in the dialog, the input field does not respect the set formatting and locale. Instead the browers formats the This seems to be a known issue in the react-datepicker project, but there seem to be no plans to fix it. react-datepicker allows us to use our own, custom time input component, so we could implement that. However, properly implementing a time input component is non-trivial (and a reason to use a library). So I do not want to implement such a custom component in this PR, or at all really. But even if with this issue present, I think this PR constitutes an improvement over the current state of things and would still like to see it merged. |
3 participants
This patch aims for a consistent date display across the entire ui. That it is not always consistent can be seen for example in the event details metadata, where the start date is formatted differently from the created date.
Furthermore, this patch aims to base date formatting more on the chosen locale to create a more intuitive experience for users. No more A.M./P.M. in the german locale for example.
To achieve this, date-fns is chosen as the gold standard and momentjs is removed from the project completely. Not only because moment is legacy, but also because our datepickers were using date-fns already and will not use anything else.
Additionally, this removes our custom date formatting from the translation files and replaces it with date-fns tokens. In my opinion, we do not need to try and be smarter than our datetime library when it comes to formatting dates. Translators retain the ability to enforce their favourite formatting should they so chose,
but will have to be aware that it will not be respect everywhere, e.g. not in the datepickers.
This patch contains changes to all translation files. I am aware that everything except en_US will get overwritten, the changes to other languages are merely for ease of reviewing. If this patch is merged, the translations should be adapted asap as per this example.
Before:
After:
Fixes #1279
How to test this
Can be tested as is. Check anything with dates. Special attention should be payed to the statistics tab and scheduling. Ideally we get people who use other locales apart from the english ones to test this, so they can mention if anything looks very odd in their favourite locale now.