Fix "Typing in date input ends early"

[Arnei]

Trying to type in a date in for example the start date table filter is not working. The input is interpreted as a date immediately. For example, typing "1" will result in "01/01/2025", even if you wanted to type something completely different.

This patch fixes that by enabling strict parsing. Arguably not the best solution, but it works for now.

[github-actions]

Use docker or podman to test this pull request locally.

Run test server using develop.opencast.org as backend:

podman run --rm -it -p 127.0.0.1:3000:3000 ghcr.io/opencast/opencast-admin-interface:pr-1084

Specify a different backend like stable.opencast.org:

podman run --rm -it -p 127.0.0.1:3000:3000 -e PROXY_TARGET=https://stable.opencast.org ghcr.io/opencast/opencast-admin-interface:pr-1084

It may take a few seconds for the interface to spin up.
It will then be available at http://127.0.0.1:3000.
For more options you can pass on to the proxy, take a look at the README.md.

[github-actions]

This pull request is deployed at test.admin-interface.opencast.org/1084/2025-01-23_11-52-45/ .
It might take a few minutes for it to become available.

[owi92]

At first the date input seems to be working fine on main. But there are a couple of weird things when trying different things.
I meant to list them here, but that list got convoluted rather quickly and won't help anyone, I suspect.

As you already noted, enabling strict mode isn't a great solution, and I expect users might complain about that even more than the current status if they don't know that they need to strictly adhere to the rules of their respective date format (i.e. with German as selected language, users need to type "dd.mm.yyyy", with English(US) they need to type "mm/dd/yyyy", while English(UK) allows both "dd.mm.yyyy" and "dd/mm/yyyy")). These were the only languages I tested.
Adding tooltips might help, but that gets out of hand quickly with all the different languages.

So yeah, I don't know what the best solution for this is either. Maybe this is something to bring up in technical meeting, but I don't feel up to the task of explaining exactly everything that is wrong with the current version.

[Arnei]

To summarize your words in my own:

1. This PR should not be merged, as strict mode offers a bad user experience.

Fair enough, I definitely agree that forcing users to correctly know the default date scheme for the currently selected language is not great UX. I still believe that being forced to adhere to date schemes is better than not being able to type in the date at all.

2. There are many, complicated issues with the date input

There are multiple ways we could act on that statement, but without a more detailed info on what you are talking about it is hard to say. Are those issues worth fixing? Was introducing react-datepicker a bad idea after all?

[owi92]

TLDR: just go with strict mode for now

Ok, I'll try to list the "issues" I have with the current status of this on main (which are more or less subjective). I'm afraid that it might be a little hard to follow and it won't be a complete list, but I'll do my best. I will focus on the start date filter, assuming this applies to other instances of the date picker as well. All of these observations are made with a freshly instantiated filter on the main branch and if not specified otherwise, they happen in both Chrome and Firefox:

• The most apparent issue is that the pop up calendar doesn't reflect the date that is being specified, with a few exceptions, as it always shows the current month (i.e. right now it's stuck on January 2025).

The following observations are made with German as selected language:

• Typing a number < 31 will select that day in the popup, so far so good
• When a month is specified, i.e. entering "11.5" (without the second delimiter), this will internally select May 11th 2025, but as noted above the popup is still showing January
• Pressing enter now will lock in May 11th 2025 (which is expected, I suppose)
• Chrome only: If before pressing enter the second delimiter is added (i.e. the input now being "11.5."), the internally selected date will be November 5th 2001, at least that is what's locked in when pressing enter. However if the first number was > 12, say 13, this will instead resolve to May 13th 2025
• In Firefox, this would still resolve to May nth 2025
• Entering a complete date (i.e. 4.11.23) and pressing enter resolves to April 11th 2023 in both Firefox and Chrome
• Again, if the first number was n > 12, then it will instead resolve to November nth 2023

Repeating similar tests with English(US) selected:

• Typing a number < 13 will select that month in 2025. I.e. entering 12 and pressing enter locks in December 1th 2025 (that behavior is alright)
• Typing a number > 12 and pressing enter will select January 1st 2025 (no matter if it's followed by a second or third number, i.e. "14.3.23" is still January 1st 2025, which is alright as that date isn't really parsable in the US representation)
• Entering "12.3." and pressing enter will select December 3rd 2001 in Chrome
• Doing the same in Firefox produces December 1st 2001 (what? I swear, I am not making this up)
• (Entering "12.3.12" at least produces the correct date of December 3rd 2012)

Finally, looking at English(UK):

• Input of "n" selects January nth 2025
• Input of "11.4." selects selects November 4th 2001 in Chrome and November 1th 2001 in Firefox (again, what the...)
• and the remaining results for the above inputs mostly seem to mirror the results of English(US)

If I understand you correctly, it is not possible for you to enter any date at all, but that specific behaviour I cannot reproduce. However, that being the case for you, it's safe to assume this applies to other people as well, and under that assumption I agree that using strict mode is preferable. And at any rate, I don't think the issues I listed above can be easily fixed. Also, others might not perceive or notice them as issues at all.

My original comment was more to say that I don't feel comfortable to decide this on my own. Though I am leaning towards saving the one making the decision (and I think it's fair if you do that) the headache of trying to make this work without strict mode, and suggesting to go ahead and merge this. If you agree, I'll gladly approve this.