Pull Request for Issue # .

Summary of Changes

This PR fixes the one and only datetime column date_time of the com_messages database table #__messages so there will not be any Invalid value '0000-00-00 00:00:00' for datetime error anymore on MySQL 5.7 or later when strict mode is enabled.

The column will be handled like the created column of the #__banners table in PR #26372 , i.e. it will have no default value anymore. This will enforce to insert new records with values for this column being provided and throw an SQL error if some of these values is not specified, i.e. such errors will not be hidden anymore. In the same way as for the created column of the #__banners table in PR #26372 , old data will not be updated. It can be assumed that messages created by the core don't have value '0000-00-00 00:00:00' for the date_time column.

In opposite to PR #26372 , this PR here does not depend on PR #26295 , because this one here does not have anything to change in table #__ucm_content.

This PR here does not include any changes to PHP code because I haven't found anything which needed to be changed.

Testing Instructions

Can be tested by code review, but in addition you can do a test for new installation as follows:

1. Apply the patch on a clean 4.0-dev branch using git or merging manually, or apply it on an installation of current 4.0-dev using patchtester.
2. If used patchtester on an existing installation in step 1, delete file configuration.php and delete all Joomla database tables in PhpMyAdmin or PhpPgAdmin (depending on your database type).
3. Do a new installation, login to backend, confirm the statistics dialog, go to global config and set error reporting to maximum or development in server settings.
4. Check that com_messages workes as well as without this PR.

Expected result

com_messages works as well as without this PR. There is no record with value '0000-00-00 00:00:00' in column date_time of table #__messages in a MySQL database. The default value of this database column is not invalid anymore in MySQL.

Actual result

Same as expected result, but the default value of this database column is invalid in MySQL >= 5.7 with strict mode on.

Documentation Changes Required

Maybe core developer docs and extension developer docs should be updated to encourage them not to use '0000-00-00 00:00:00' on MySQL anymore but use real NULL and not abuse '1970-01-01 00:00:00' on PostgreSQL as a speudo null date anymore and use real NULL values also there.