In one environment, the parsing of the date of a post through IntlDateFormatter returns false (i.e. a parse error) because it does not deal well with the pattern that contains a dot after the month:
new \IntlDateFormatter( $this->context->getLocaleResolver()->getLocale(), \IntlDateFormatter::MEDIUM, \IntlDateFormatter::SHORT, null, null, 'MMM. d, y h:mm a' );
in Controller/Adminhtml/Post/Save.php
As a result of this, if you edit an old post, its created (published) date is always overwritten with a default date (current timestamp in the database) and you can not put it back.
The pattern contains a dot after the month, but this is not present in the actual data. Removing the dot fixes the issue.
The dot was causing issues only one environment though, with 2 others being fine.
Now, if you look at Block/Adminhtml/Post/Edit/Sidebar/Publish.php, there date_format is defined as
In one environment, the parsing of the date of a post through IntlDateFormatter returns false (i.e. a parse error) because it does not deal well with the pattern that contains a dot after the month:
new \IntlDateFormatter( $this->context->getLocaleResolver()->getLocale(), \IntlDateFormatter::MEDIUM, \IntlDateFormatter::SHORT, null, null, 'MMM. d, y h:mm a' );in Controller/Adminhtml/Post/Save.php
As a result of this, if you edit an old post, its created (published) date is always overwritten with a default date (current timestamp in the database) and you can not put it back.
The pattern contains a dot after the month, but this is not present in the actual data. Removing the dot fixes the issue.
The dot was causing issues only one environment though, with 2 others being fine.
Now, if you look at Block/Adminhtml/Post/Edit/Sidebar/Publish.php, there date_format is defined as
'date_format' => 'MMM d, y'without the dot. So is this a bug?