@alikon Doesn't it need to do the same changes in the existing schema updates, too, at least in those for 4.0.0?

sounds reasonable
done

btw, outside the scope of this silly PR + we still need to full manage null as a date value all over the core code

We've already agreed to convert basically all the instances you are touching here to actual null. (REF: #21901 or #25360)

I don't plan on merging this until we've converted all core to use null where it makes sense to (e.g. checked out times and modified at times) and then can see what individual items are remaining

@wilsonge The problem is: The log of Hannes' new system tests for MySQL 8 shows that the '0000-00-00 00:00:00' dates are a problem. And there is rumor in issue here and in forums why we fail on MySQL 8. Maybe this PR here will be a faster help with that than the real nullable dates?

I agree with you in general, this PR here is useless if all of these columns will be made really nullable. But will we have that soon enough? Really all of them?

Or maybe test and merge this one here soon as a quick fix before the reaul stuff comes?

If so, we should wait until Hannes' PR #25615 is merged. Then @alikon could update with latest changes from 4.0-dev and solve conflicts, and then we see in the log of Hannes' new tests if the date thing was the only problem or if we have more and which ones maybe.

I understand that it doesn't work in MySQL 8. I think you'll find the same thing in MySQL 5.7 too actually. It's not really any more work to create PRs like the two I linked to as do this. And it's possible there might be some null date's left over at the end in which case we will still need this. But it won't be as widely used as this