In what scenario with current joomla can you ever have a date of 0000-00-00?

Thanks for your question, While 0000-00-00 is not something you did normally see in the current Joomla system it can still show up in some rare cases like when a database field is set to a zero date or when old data is imported from another system. This fix makes sure those cases don’t cause problems in SmartSearch by handling them properly. If you feel this scenario doesn’t really need to be covered, I can simplify the logic. Let me know what you think.

I will leave it to others to decide but to me this stinks of ai generated code that doesn't understand where the code is being used. I cannot imagine any scenario where this code will ever see such a value.

Okay, let me fix it from my side.

Sir, the main fix is handling null and empty ('') values for publish_down, since those cause some SmartSearch issues.
I add checks for '0000-00-00 00:00:00' and '0000-00-00' as a safeguard for legacy or malformed data.

In such a case, is there a kind of cleanup procedure to be launched during upgrade in order to fix the already indexed articles ? Or just an instruction note asking to clear the index and rebuild it ?

Fix makes sure the new indexing handles publish_down dates correctly by setting publish_end_date to null but for articles it is already indexed with wrong values so there a cleanup is needed. So basically there will be two options

1. Add note in the released docs with asking users to clear and rebuild the index after upgrading and all
2. Make a migration script to automatically reset incorrect publish_end_date values
   If you prefer I can work on adding the automated cleanup so the fix also applies to old indexed articles.

You should follow the usual way of doing in the Joomla's developpers community. I've no clue what are the habits.

Sir, I’m new to Joomla and tried to make the cleanupDate() method handle edge cases like '0000-00-00 00:00:00' for safety. If this isn’t needed, I can simplify it to only handle null and empty strings, since those cause the issue. Please let me know the right approach so I can update the code.

@kartikeyg0104 To me this PR looks like snake oil.

The existing code (without this ) does a type cast to integer before checking != 0 for the ternary expression. So an empty string, null, an old zero date or old zero datetime, all that will be zero when casted to integer. That should work well.

In which scenario does it not work? I would expect issues at other places when using an old zero date or zero datetime, but not here in the code changed by this PR.

If you cant provide a valid scenario where the old code has a problem, then this PR will not be accepted.

Sir, the old logic (int) $date != 0 is not reliable for all date strings. For example if '2024-12-25 10:30:00' becomes 2024 when cast to int which is not correct for date checks also in some legacy or migated Joomla sites values like '0000-00-00 00:00:00' or '0000-00-00' still exist. The old logic doesn’t handle them properly, which can leave invalid publishdown dates in the index and exclude artcles from SmartSearch.
The updated cleanupDate() makes sure only valid dates are kept and everything else (null, '', '0000-00-00', '0000-00-00 00:00:00', etc.) is set to null. This ensures articles don’t get wrongly excluded and improves SmartSearch reliability even for legacy data.

For example if '2024-12-25 10:30:00' becomes 2024 when cast to int which is not correct for date checks

@kartikeyg0104 Nonsense as the cast to int is used only in the condition of the ternary expression but not in the return value of the ternary for the case if it is true. So there is no date check logic applied on the 2024 in your example.

in some legacy or migated Joomla sites values like '0000-00-00 00:00:00' or '0000-00-00' still exist.

Also nonsense as Joomla 5 amd later require MySQL versions >= 8, where using the old zero dates or zero datetimes will result in an SQL error when trying to import such data or insert such data.

Only on MariaDB such old date or datetime values might still exist.

But any import tool which claims to be compatible with Joomla 5 or 6 has to support both, MySQL and MariaDB, and for MaSQL Joomla's version requirement makes sure that the version is >= 8.

Your long explanations still have not provided a valid practical use case, only theoretical things based on assumptions (which party are wrong).