Date/time field: unexpected results for arbitrary formats

[animaux]

Description

When pasting or writing dates in times in their respective fields, in formats that do not match the final format, the values are intrepreted in strange ways with even the year switching on or two years. This can easily be overlooked by editors and leads to wrong dates being saved.

Apparently english dates with named months are interpreted correctly, but even those only when using day-month-year (which is the proper way of course :).

Of course everything works fine when using the predefines format and we cannot expect every arbitrary format to be interpreted correctly.

But since editors are expected to use shortcuts (like simply pasting data as it is), it would be nice to have either a decent interpretation in the panle language or a message urging the user to use a proper format if it can’t be interpreted properly.

Expected behavior
I’d expect the fields to try to interpret the entered data in a sensible manner or throw an error if they fail to do so.

To reproduce

Not sure if this is being used in any way when interpreting input data, but the setting in the config.php is:

  'locale' => 'de_DE.utf-8',

  …

  'date'  => [
    'handler' => 'intl'
  ],

User language in the panel is set to german.

Time Field

entered/pasted value	expected resulting value	actually resulting value	good/bad
12.05	12:05	12:05	👍🏻
12,05	12:05	12:05	👍🏻
12,45	12:45	12:45	👍🏻
1111	11:11	11:00	❌
1234	12:34	12:05	❌
1245	12:45	12:05	❌

Date Field (DD.MM.YYYY)

entered/pasted value	expected resulting value	actually resulting value	good/bad
02.03.2024	02.03.2024	02.03.2024	👍🏻
02-03-2024	02.03.2024	02.03.2024	👍🏻
2024-03-02	02.03.2024	02.03.2024	👍🏻
2.3.2024	02.03.2024	02.03.2024	👍🏻
2 3 2024	02.03.2024	02.03.2024	👍🏻
02032024	02.03.2024	02.08.2026	❌
2. März 2024	02.03.2024	02.08.2025	❌
March 2 2024	02.03.2024	02.08.2025	❌
March 2. 2024	02.03.2024	02.08.2025	❌
2. March 2024	02.03.2024	02.03.2024	👍🏻
23. Juni 2024	23.06.2024	23.08.2025	❌
23. June 2024	23.06.2024	23.06.2024	👍🏻

Your setup

Kirby 4.1.0
PHP 8.2.13

Your system

• Device: mac Mini
• OS: macOS 14.3.1 (23D60)
• Browser: Safari
• Version: 17.3.1

[distantnative]

@animaux did you mix up the actual vs. expected columns?

[animaux]

Yes, absolutely, sorry, thanks. I switched it for the date as well now, since I feel it is more easily readable that way.

[bastianallgeier]

Please ignore my stuff. I assigned the wrong issue in a totally unrelated PR by accident 🙈

[distantnative]

@animaux This one is really hard. I am trying to add some more patterns, but this will only help with some of these formats. The difficult part here is that the dayjs library is not failing to parse the dates - then we could simply communicate this. But it will match the input to different formats as it is very easy to do so when all the formats looking very similar. And thus you get unexpected results instead of errors.

And there currently is not good way to offer support for other languages than English.

[animaux]

Thanks for getting into this. Most of the Date examples are likely edge cases, apart from the straight forward Day-Monthname-Year dates in non-english languages (like 23. Juni 2024), which should at least work for the selected panel language, I feel.

I hope it’s not as difficult for the time field. I think it would be a sensible default to assume HHMM for any four-digit number entered.

[distantnative]

which should at least work for the selected panel language, I feel.

As I wrote, supporting other languages than English with the dayjs library is not quite feasible so far.

Time should work when #6362 gets merged.