I would stay away from strtotime it has limit to 2038 year, and retun unexpected results for the dates that does not fit to "Unix epoch"

DateTime::__construct() [datetime.--construct]: can be esialy fixed with try/catch http://php.net/manual/en/language.exceptions.php

strtotime requires an english date (YYYY-MM-DD) while the calendar field actually would accept any date that PHP can detect. Which for example may also be the german format DD.MM.YYYY.

@Bakual I think your comment is not correct. strtotime doesn't require the value in YYYY-MM-DD format. For example, this simple command does work echo date('d-m-Y', strtotime('20.11.1984'));

Interesting, because the PHP manual says otherwise: http://php.net/manual/en/function.strtotime.php

strtotime — Parse about any English textual datetime description into a Unix timestamp

There are many formats accepted http://php.net/manual/en/datetime.formats.php. I think Joomla core JHtml::calendar uses the same code, too https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/html/html.php#L982

I improve the code a bit to check and make sure the value not only a valid date Datetime string but also have to meet the format defined by format attribute of the form field.

JHtml::calendar uses the same code, too

That one is actually when it will be displayed. At this time, $value always is in YYYY-MM-DD format as it is coming from the database. So it's not the same case.
But if it works with other formats as well, then it should be fine.

I improve the code a bit to check and make sure the value not only a valid date Datetime string but also have to meet the format defined by format attribute of the form field.

That would be wrong. The format parameter is meant to specify how the date is displayed. How it is entered doesn't matter at all as long as PHP can detect it. So you would enforce more than is required.

@Bakual OK, So I mis-undertood the format parameter. If so, the code could be simpler, just simple use try / catch as @Fedik suggested. I will update the code.

Yeah, I think that try/catch should work fine.

I have tested this item unsuccessfully on 8c6b481

I tested this by adding an invalid date in the published date field of a news feed. When pressing save I expected an error message but instead the item was saved but with no value in that field

I have tested this item ✅ successfully on 8c6b481

I have tested this patch successfully with the follow test-entries in the field(Finish Publishing):

Warning
Value 12.oo.2016 you entered for Finish Publishing is invalid datetime format

Warning
Value 30.##.2016 you entered for Finish Publishing is invalid datetime format

Warning
Value 30 06 2016 you entered for Finish Publishing is invalid datetime format

Warning
Value 34 14 2016 you entered for Finish Publishing is invalid datetime format

Warning
Value 2020 ü 1f you entered for Finish Publishing is invalid datetime format

Tested @icampus

I have tested this item ✅ successfully on 8c6b481

Works as described @icampus

Value 201608-30 12:9:16 you entered for Start Publishing is invalid datetime format

@joomdonation #11138 should be a better solution (although that will be client side as your approach here is server side)

@dgt41 Haven't looked at your PR carefully yet but does your PR prevents users from entering date in wrong format (manually) ?

@joomdonation yes, the field is readonly and the changes are made only through the popup calendar (which is also accessible)

OK. Then in this case, I will close this PR (not really happy with the code on this PR too).

Thanks everyone for feedback and testing