Investigate why deleted liveblog entries have empty comment_date_gmt

[GaryJones]

Background

PR #829 fixes a fatal error in the /entries REST endpoint caused by deleted liveblog entries having an empty comment_date_gmt. The fix there is defensive: DateTimeImmutable::createFromFormat() now returns false for empty/malformed dates, and we fall through to mysql2date().

That addresses the symptom, but leaves two open questions worth a follow-up.

Root cause to investigate

1. Why is comment_date_gmt empty on delete entries? A standard WP comment delete workflow shouldn't blank the GMT date. Is this the result of a custom delete path in liveblog, historical data, or something else?
2. Should deleted entries be filtered out of the /entries endpoint earlier? If the endpoint is returning deleted-type comments but downstream code can't meaningfully render them, filtering at the query level might be the right fix.

Related concern

WPCOM_Liveblog_Entry::get_timestamp() (classes/class-wpcom-liveblog-entry.php:170) uses mysql2date( 'G', $this->comment->comment_date_gmt ) directly. It won't fatal error like the /entries path did, but it will silently return false for deleted entries with empty dates. Worth covering this path during the root-cause work.

Also worth deciding

• When get_comment_date_gmt() can't produce a timestamp, should it return false (current behaviour), 0, or something else? The JSON output at for_json() currently includes 'entry_time' => $this->get_comment_date_gmt( 'U', $entry_id ) which will emit false in this edge case.

Related

• PR Fix fatal error in /entries endpoint #829 — defensive fatal-error fix
• Commit 1dbcf5e — original DateTimeImmutable change that introduced the fatal

[GaryJones]

Fallback behaviour now diverges between 1.x and 2.x

Worth capturing before this work starts — the two branches mask the underlying issue differently, and neither is obviously correct.

1.x (PR #829, now merged): falls through to mysql2date(), which returns false for an empty date. for_json() then emits "entry_time": false in the REST response.

2.x (src/php/Infrastructure/Repository/CommentEntryRepository.php:418): substitutes new DateTimeImmutable( 'now', ... ). A deleted entry would appear in the JSON with the current timestamp, not the original — which could be misleading in client-side rendering.

Deciding the right contract for an entry with no usable comment_date_gmt (boolean false? 0? null? created-at-read-time? filter out entirely?) is part of this work, not something to settle in isolation on either branch.