Comment 1 for bug 1455137

Hi David,

I've confirmed this problem. For now, the workaround is to change calendar_dateFormat and strftimedatetimeshort back to the originals from the English langpack. (And update the lang strings for the help text, to match.) I've looked through the code and verified that calendar_dateFormat and strftimedatetimeshort are nearly only used for the JS calendar widget (strftimedatetimeshort also has a couple of other minor uses, usually in outputting data to admins).

Going forward, here's what I would suggest for the fix:

1. For the calendar, instead of using "strftimedatetimeshort", we use a new lang string called "calendar_phpdatetimeformat".

2. We rename "calendar_dateformat" to "calendar_jsdateformat", and "calendar_timeformat" to "calendar_jstimeformat".

3. Items #1 and #2 together should help make it clearer to devs that these strings must match each other.

4. If possible we add some code to the Pieform calendar and acl elements, so that they themselves do the date format validation, and so that they render the human-readable date into a hard-coded format by the time it gets sent to the form's "_submit" function. That way, we won't have to rely on the devs remembering to use the correct lang strings to parse and validate the calendar's dates on every form where it is used. (It is evident we devs have not been remembering to do that.)

5. If #4 is not possible, at least add some documentation to the Pieform calendar and acl elements. And go through all the forms that use them and fix their validation and submission code.

Unfortunately, this is a non-trivial fix, so I'm probably not going to get to it immediately. In the meantime, I'd suggest using that workaround, of changing calendar_dateFormat and strftimedatetimeshort back to the original values. This shouldn't be a huge inconvenience to your users, because the JS calendar widget means they shouldn't actually need to type in a date anyway.

Cheers,
Aaron