I used Claude to assist me in creating this issue:
Description
When a post is in a custom Edit Flow status (e.g., Pitch, Assigned, or any user-created status) the block editor displays a concrete date (e.g., "April 6 2:42 pm") instead of "Immediately" in the publish date field.

Without Edit Flow active, the same database state correctly shows "Immediately" for draft and pending posts.
Steps to reproduce
- Fresh WordPress install (tested on 6.8), install and activate Edit Flow
- Enable Custom Statuses module (enabled by default)
- Create a new post, save it (it will be in "Pitch" status by default)
- Look at the sidebar — the Publish field shows a concrete date like "Today at 2:44 pm"
- Deactivate Edit Flow
- Reload the same post — the Publish field now shows "Immediately"
Expected behavior
Posts in custom Edit Flow statuses with an unset GMT date should show "Immediately" in the block editor, matching WordPress core's behavior for draft and pending statuses.
Root cause
Claude's diagnosis:
WordPress core's WP_REST_Posts_Controller::prepare_item_for_response() has special handling for draft and pending statuses — when post_date_gmt is '0000-00-00 00:00:00', it returns null for date_gmt in the REST API response. The block editor interprets null as "Immediately."
Edit Flow's custom statuses (Pitch, Assigned, In Progress, Hold, etc.) are not recognized by this core logic. When the REST API serializes a post in a custom status, it converts '0000-00-00 00:00:00' to a real ISO 8601 date derived from post_date. The block editor stores this concrete date, displays it, and sends it back on subsequent saves — preventing core's "reset to now on publish" behavior.
The fix_custom_status_timestamp() method in EF_Custom_Status correctly preserves '0000-00-00 00:00:00' in the database on save. But the REST API round-trip converts it to a real date before the block editor ever sees it.
Impact
- On publish, the posts do publish with the correct date. However, its confusing to editorial.
Environment
- WordPress 6.8
- Edit Flow 0.10.3
- PHP 8.2+
- Reproduced on clean installs with no other plugins active
I used Claude to assist me in creating this issue:
Description
When a post is in a custom Edit Flow status (e.g., Pitch, Assigned, or any user-created status) the block editor displays a concrete date (e.g., "April 6 2:42 pm") instead of "Immediately" in the publish date field.

Without Edit Flow active, the same database state correctly shows "Immediately" for draft and pending posts.
Steps to reproduce
Expected behavior
Posts in custom Edit Flow statuses with an unset GMT date should show "Immediately" in the block editor, matching WordPress core's behavior for
draftandpendingstatuses.Root cause
Claude's diagnosis:
WordPress core's
WP_REST_Posts_Controller::prepare_item_for_response()has special handling fordraftandpendingstatuses — whenpost_date_gmtis'0000-00-00 00:00:00', it returnsnullfordate_gmtin the REST API response. The block editor interpretsnullas "Immediately."Edit Flow's custom statuses (Pitch, Assigned, In Progress, Hold, etc.) are not recognized by this core logic. When the REST API serializes a post in a custom status, it converts
'0000-00-00 00:00:00'to a real ISO 8601 date derived frompost_date. The block editor stores this concrete date, displays it, and sends it back on subsequent saves — preventing core's "reset to now on publish" behavior.The
fix_custom_status_timestamp()method inEF_Custom_Statuscorrectly preserves'0000-00-00 00:00:00'in the database on save. But the REST API round-trip converts it to a real date before the block editor ever sees it.Impact
Environment