The date thing should become obsolete when our works on the datetime columns will be finished. I’ll put it on the task list which we have in Glip.

@richard67 that is unrelated

@brianteeman. No, it is not. @wilsonge Please check and confirm.

It's unrelated. The updateDates function sets various dates to the current time (as of when that function runs) for a newly installed site. So instead of having a null date for your created date of the default uncategorised categories or your super user account's registration date, those are set to what is in essence the time the site was created. So the only thing it has to do with the rest of the work you're doing for the date/time fields is ensuring that query is correctly updated to match up with whatever the defaults in the joomla.sql file are.

So the only thing it has to do with the rest of the work you're doing for the date/time fields is ensuring that query is correctly updated to match up with whatever the defaults in the joomla.sql file are.

Not even that. The issue raised here is that there are fields/tables being checked with these functions that will never need to be checked and other fields/tables that should be checked with these functions which are not

I see. Well, after my changes there will not be a null date anymore for created and modified columns, and for the others we will use real NULL values, so that function will need to be updated at least. Thanks toy Brian for opening this issue so I got aware of that.

You are still missing the point completely of this issue it is nothing to do with null dates - spend two seconds reading the code and you will see that.

I see.

see #26399

re-open as although the current code is wrong it doesnt address the issue of localise or custom.sql

@brianteeman Please test PR #26825 for the datetime part. The user ID part is handled with PR #26745 .