[UX] Ignored date format of content type

[VasasA]

Description of the bug
When I create a new content type with a new date format, I see an error message when I add a new content : The value input for field Date is invalid: The date "2019.09.17. 05:02PM" does not match the expected format.

Steps To Reproduce

1. Add new date format without "AM/PM" (Y.m.d. - G:i):
   

2. Add new content type with a date field of the new format:
   
   
   

3. Add new content:
   

Actual behavior
The time input field ignores the date format, "AM/PM" cannot be deleted, so the value will be invalid.

Expected behavior
The time input field's date format doesn't contain the "AM/PM", allows 24-hour format of an hour without leading zeros.

Additional information
Version: 1.14.0

[olafgrabienski]

@VasasA Have you seen issue #3972? It sound very similar to me.

[indigoxela]

I think, this issue is related, but not exactly the same. The question is: why does the popup calendar widget add "AM/PM", although neither "a" nor "A" is set in the input format pattern.

It seems, date format handling is only correct, if using "H" (24-hour system with leading zero).

[indigoxela]

The problem is that date.elements.inc only considers "H" to be a 24-hour format:

https://github.com/backdrop/backdrop/blob/780e8d8c2bbd2be35e4cd057f279569f49fed93a/core/modules/date/date.elements.inc#L1158

And if "show24Hours" is not in the widget settings, jquery.timeentry.js (the js library in use) will add am/pm no matter what the pattern is.
So this is actually unrelated to #3972.

I'm not sure, if date validation still would work, if we added "G" to set "show24Hours".

Anyone willing to dig into this?

[olafgrabienski]

So this is actually unrelated to #3972.
(...)
Anyone willing to dig into this?

Thanks for the clarification! Unfortunately beyond my skills.

[VasasA]

@indigoxela and @olafgrabienski Thank for the mentions.
I tried the Y.m.d. - H:i format string, and it generetes a similar error message:

[VasasA]

I improved this line: https://github.com/backdrop/backdrop/blob/780e8d8c2bbd2be35e4cd057f279569f49fed93a/core/modules/date/date.elements.inc#L1158
with handling the 'G' format:

'show24Hours' => (strpos($element['#date_format'], 'H') !== FALSE || strpos($element['#date_format'], 'G') !== FALSE) ? TRUE : FALSE,

It also generates same error:

[VasasA]

Parse function:
https://github.com/backdrop/backdrop/blob/780e8d8c2bbd2be35e4cd057f279569f49fed93a/core/includes/date.class.inc#L425

[indigoxela]

I see an extra dot in your screenshot: 2019.09.19. - at the end of the date. Have you tried without that dot? It works fine here without it.

However, it seems, something's wrong with either date object creation in date.class.inc or the way the popup calendar widget handles patterns.

To my surprise, there's no DateTime::createFromFormat anywhere in the parse function, which would be much easier.
Anyway, @VasasA it seems, you found a "dusty corner", which needs attention.

[indigoxela]

Forgot to ask: @VasasA do you see these errors only with the date popup widget, or are they the same with select list or textfield input?

[VasasA]

@indigoxela I tested the date format without dot at the end of the date. It works fine, but this dot cannot be omitted in the Hungarian language.
It also works with select list and text field input fields.

[indigoxela]

...this dot cannot be omitted in the Hungarian language.

Input formats are a lot trickier than output formats, as php has to parse it somehow. It seems, the popup calendar library and the timepicker library aren't your friends in this case, either.

I'm not sure, if Backdrop can do much for you in this case. Let's hope, someone with a better idea chimes in.