I have tested this item ✅ successfully on f1ba93b

Works as described backend and front.

Note: The descriptive label for the front birthday field would also need to be adjusted accordingly in the language files. Tested with German de-DE and the text above the birthday entry field says "Das Geburtsdatum muss im Format Jahr-Monat-Tag (z. B. 1980-12-01) eingegeben werden." which is opposite to the new changed format added in de-DE inis.

The descriptive label for the front birthday field would also need to be adjusted accordingly in the language files.

True enough, the language files need to be updated. However not sure what we can do with this PR since the english string is actually fine. Probably just needs a notice in the translators forum.

Agree, simply something for the language pack creators to have attention to in the case they use other format than specified en-GB.

?
Indeed, this should be explained to TTs.

I have tested this item ✅ successfully on f1ba93b

RTC @Bakual please sync to staging (there should be a button) to fix the travis problems :)

@Bakual
I suggest to add a comment before the following langstring in /administrator/language/en-GB/en-GB.plg_user_profile.ini, with no empty line before and after.
i.e.:

; Adapt the following string to the format you entered in the 'DATE_FORMAT_CALENDAR_DATE' 
PLG_USER_PROFILE_SPACER_DOB="The date of birth entered should use the format Year-Month-Day, ie 0000-00-00"

Rebased on 3.7.x branch and added comment.

I have tested this item ? unsuccessfully on 639dac8

DateTime::__construct(): Failed to parse time string (09.20.2016 20:30:16) at position 8 (1): Unexpected character

Format: %m.%d.%Y %H:%M:%S

There must be a conversion from the selected format after submitting the form or there are only a few formats allowed: http://php.net/manual/en/datetime.formats.php

I had a look at that page earlier and couldn't figure out which formats are accepted and which not. I found it quite confusing. But I found out that "5th october 2016" actually works with our calendar field ?

I have a look if we can use a server side validation rule to improve the possible formats.

I think the formats in the tables after the first table are accepted ? (The examples are good).

I had a look at server side JFormRules. Unfortunately they can't change the values, they just can test them and return true/false. Or at least I couldn't figure out a way.
That means each extension would have to check the dates and adjust the format in their code, which isn't ideal as it means duplicated code all over the place.

Does someone know a way to "post process" a formfields value on a library level (outside the extension)? I'm not aware of it but I may miss something.

@Minei3oat Can you test again? I make now use of the already existing filters user_utc and server_utc. They will now check the date and convert it according to the specified format.
Unfortunately we can't parse the date using the %Y-%m-%d format spec. The function strptime which would do exactly that doesn't exist on Windows systems. So I had to use date_parse_from_format which uses the Y-m-d spec. That means two additional language strings.

On a side note if someone wonders: date_create_from_format doesn't work because when the format is only partial met (eg no seconds entered), it will fail.

I have tested this item ✅ successfully on 474b7de

On a side note if someone wonders: date_create_from_format doesn't work because when the format is only partial met (eg no seconds entered), it will fail.

Do you mean that, for a birthday date one would have to enter hour minutes seconds or that one could still do only d-m-Y and IF using hours, making sure hour AND minutes AND seconds should be entered?

Do you mean that, for a birthday date one would have to enter hour minutes seconds or that one could still do only d-m-Y and IF using hours, making sure hour AND minutes AND seconds should be entered?

No, the current code works when you enter only a partial date/time value. I'm not using date_create_from_format in the code. I just wrote it because it would seem the simplest and obvious function to use, but as I wrote it fails in our case.
So to be completely clear: For the birthday date where showtime is false, you don't have to specify the time at all. For the other calendar fields where showtimeis true, you can omit part of the time. It will be replaced with 0 then.

Rebased so hopefully the unrelated Travis error is now gone.

The new attributes are added here: https://docs.joomla.org/Calendar_form_field_type please coerrer any errors there. Thanks ?

Perfect, thanks a lot for taking care of it!