Since this is a really serious problem for many users and extensions, a prioritization and quick update of the Joomla version would be necessary. Can it be forced somehow and raised in priority?

Filter format comes from translation, DATE_FORMAT_FILTER_DATE or DATE_FORMAT_FILTER_DATETIME
or from field XML declaration.

Please check if it works on default "en-GB".
Maybe it is translattion problem, wrong format string or something.

5.1.x - saved date format (German):
Filter Format: 'd.m.Y H:i:s'
Date: '2024-04-18 12:13:48' ... ERROR (dots instead of -)

The filter format and display format are diferent. that why you get an error.

5.1.x - saved date format:
'Y-m-d'
'2024-04-18 13:21:58' ... ERROR

The filter format and display format are diferent.
Probably \DateTime::createFromFormat() is strict, and even when the day format match, the time are not.

See my previous post, sometimes, the problem is only different language but sometimes the problem is the format itself (e.g. additional time to date). All changed in 5.1.x, everything is OK in 5.0.x. It is defined in XML, so hard to say, if there is some intermediate step which can influence this on component level. :idea:

Something wrong with filter format/display format.
On quick look I do not see any related changes in 5.1 for the Calendar field itself.

If you run:

var_dump(\DateTime::createFromFormat('Y-m-d', '2024-04-18')); // Works
var_dump(\DateTime::createFromFormat('Y-m-d', '2024-04-18 13:21:58')); // False result

Need to debug whole stack.

Yes, I don't see any changes in Calendar field too:

removed: use DateTime; (should not be a problem)
new: collectLayoutData (only cache change, then in calls standard getLayoutData() ... This should not have any impact on this problem.

I get the same results on 5.1 like on 5.0 with:

var_dump(\DateTime::createFromFormat('Y-m-d', '2024-04-18')); // Works
var_dump(\DateTime::createFromFormat('Y-m-d', '2024-04-18 13:21:58')); // False result

The difference is not this but in 5.0 the form controller gets this format: 2024-04-18 but in 5.1 this format '2024-04-18 13:21:58' of canledar form field data (even the form field does not have time set)

or in 5.1 (English) checks for Y-m-d H:i:s' and in 5.1 (German) checks for d.m.Y H:i:s'

So the date format as data send to controller is different.

This is very interesting:

Removing this (or commenting it):

if ($this->layoutData) {
   return $this->layoutData;
}        

in libraries/src/Form/FormField.php method ( protected function collectLayoutData(): array )

solves the issue (of course, after removing or commenting, the cache needs to be cleaned to test it properly).

This even explains, why the problem occurs after second or another save and not after first save (after first save the date format is OK).

I need to do more tests, but it seems, this change:
collectLayoutData instead of getLayoutData can cause it (introduced in 5.1.0).

collectLayoutData instead of getLayoutData can cause it (introduced in 5.1.0).

It is fixed in #43234 (waiting for merge)

This even explains, why the problem occurs after second or another save and not after first save

yeah

Great, thank you for the info.

Is there any indication as to how quickly the update will be made available?
Unfortunately, I don't see any time windows and you can't expect customers to use the hotfix manually...

very unlikely that there will be an update before the normal scheduled 5.1.1

Thanks for answer.
This is bad and will not make users happy. Once again you have to put up with it, especially since it's not necessarily beneficial for Jan, because his Phoca extensions are widespread. Then all you have to do is wait...

I will leave the same message like in german forum here: If someone has an urgent, serious problem with this, a temporary quick fix may be to edit the following file (temporarily as a hot fix):

libraries/src/Form/FormField.php

cca line: 1353

Comment the following code:

if ($this->layoutData) {
   return $this->layoutData;
}

Then everything should be OK ( as temporarily solution).

Jan

I will leave the same message like in german forum here: If someone has an urgent, serious problem with this, a temporary quick fix may be to edit the following file (temporarily as a hot fix):

libraries/src/Form/FormField.php

cca line: 1353

Or replace the file /libraries/src/Form/Field/CalendarField.php with Fedik's solution:
https://github.com/joomla/joomla-cms/blob/8b94a618386c32d6cabccac0a888882c99999308/libraries/src/Form/Field/CalendarField.php

Since this is a really serious problem for many users and extensions, a prioritization and quick update of the Joomla version would be necessary. Can it be forced somehow and raised in priority?

This is why we have multiple beta and release candidate releases so that this type of error can be caught before release.

Why can't Joomla! be updated continuously? Like Windows offers, with additional updates?
Waiting several months for a solution that already exists is not very pleasant for end users.
This would also make it possible to check all the PRs smoothly over time, without having to make a pack with many PRs in one go. No ?

Windows releases every month but you do not know how old the items being fixed are Or what they are until they are released.

Joomla releases every month and you know in advance what is being fixed and when that release will be made.

Amazing when you compare a small group of volunteers and a trillion dollar company in the same breath and realise Joomla does it better.

Why is it that every time we post on Github, we get our ears bent?
I'm not comparing Windows to Joomla, paying to opensource, just the method of updating.
And no, you never know what's in the updates in advance.
As for the endless list of new features, Joomla! 5.1 is incomprehensible to many users: https://www.joomla.org/announcements/release-news/5907-joomla-5-1-0-and-joomla-4-4-4-are-here.html
And this doesn't help Joomla! to become popular.

, just the method of updating.

which is identical

No, sorry, there are the important ones, the packs and the security features. And the new stuff that comes along as we go along... And that you may wish you hadn't seen.
It's just a suggestion, and it would make it easier to check that the PRs are working properly.

That is a security release not a bug fix - you are comparing apples and pears.

I am genuinely intirgued how releasing a pull request immediately will

make it easier to check that the PRs are working properly

Surely alpha, beta and release candidates are a better approach.

Too few people install the alpha, beta versions etc ... This only affects developers.
A more flexible, less sectarian approach opens the door to more uses of PR before it becomes a complete package.

We need to be closer to users, to get more feedback on tests, PRs, new features, etc. Leaving the PRs on Github, or in Beta packs, etc ... is not going to advance the search for fixes for Joomla!

I'm just saying that a more flexible and voluntary approach "with installations as and when the PRs are validated" that Jooma! users will be closer to the heart of Joomla!

I'm closing this because we have a pull request. Also I will lock the discussion because it will not lead to something useful.

The suggested install every or separate patch is not possible with out current system and doesn't make things easier. Instead it's really hard for us if nobody test our releases, we changed our old "push any change into a patch release and prey nobody breaks" because too many broken releases told us it's a bad strategy.

Never the less our current strategy allows us to have tested and releases in a fixed time scheduled. Everyone can prepare there test sites for the release.

At least I'm happy with our current release cycle, it's not perfect but we learn form it and will again adapt the release plan when needed.