[huzaifaalmesbah]

What?

Part of #614. Part of #302.

Makes Helper\Serde read and write dates in UTC, and makes Factory\Message deserialize its dates the same way the other factories do.

The Message::$meta_keys, channel_title and message length changes from #614 are handled in #637, because they follow from the new v2 columns (see #627 (comment)).

Why?

• Serde depended on the PHP default timezone. maybe_deserialize_mysql_date() called DateTime::createFromFormat() without a timezone. WordPress sets the default to UTC, but anything that changes it shifts every date read from the database. It also accepted dates like 2024-02-30, which PHP silently rolls over to March.
• Factory\Message could not load a message from the database. It passed created_at / expires_at straight to the model, whose properties are typed ?DateTime, so a MySQL date string threw TypeError: Cannot assign string to property … of type ?DateTime. Implement querying the database for notifications #307 would hit this first.

How?

includes/helper/class-serde.php

• maybe_deserialize_mysql_date() parses with !Y-m-d H:i:s in UTC (! also resets microseconds).
• Dates PHP would roll over (e.g. 2024-02-30, month 13, the MySQL zero date) and non-string values now return null.
• A DateTime passed in is converted to UTC without modifying the original.
• maybe_serialize_json_date() always outputs UTC (+00:00).

includes/factory/class-message.php

• created_at and expires_at go through Serde::maybe_deserialize_mysql_date(), matching the Notification and Subscription factories.

Tests

• New tests/phpunit/tests/test-serde.php. It sets the PHP default timezone to America/New_York to prove Serde doesn't depend on it, and covers the round trip, DateTime conversion, no mutation of the input, and invalid input (including the MySQL zero date).
• test-factory-message.php: added a test that makes a message from MySQL date strings.

Testing Instructions

1. npx wp-env start
2. Run the suite:
   npx wp-env run tests-cli --env-cwd=wp-content/plugins/wp-feature-notifications vendor/bin/phpunit
3. Run it as multisite:
   npx wp-env run tests-cli --env-cwd=wp-content/plugins/wp-feature-notifications env WP_MULTISITE=1 vendor/bin/phpunit
4. Run only the affected tests:
   npx wp-env run tests-cli --env-cwd=wp-content/plugins/wp-feature-notifications vendor/bin/phpunit --filter "Test_Serde|Test_Factory_Message"

Local results: 79 tests, 0 failures on single site and multisite (the 24 skipped are the existing REST controller placeholder tests). PHPCS is clean.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5.5
Used for: Drafting the fix and unit tests. I chose the approach from the issue, agreed the split with #637, reviewed every change, and verified it locally with PHPUnit (single site and multisite) and PHPCS.

[faisalahammad]

Hi @huzaifaalmesbah, #637 and this PR both change includes/model/class-message.php, so the second one to merge will have conflicts there.

In the review on #637 this split was suggested:

• This PR keeps only the Serde date fixes.
• fix(database): add schema v2 tables #637 keeps the $meta_keys, channel_title and message length changes, because they come from the new v2 columns.

Is this OK for you? Whichever PR merges second, please check that channel_title does not come back when the conflict is fixed.

[huzaifaalmesbah]

Thanks @faisalahammad, that split works for me. I'll remove the $meta_keys, channel_title, jsonSerialize() and validate_message() changes from this PR, so it only keeps the Serde UTC fixes and the Factory\Message date deserialization (with their tests). The $meta_keys part of #614 will be covered by #637. I'll push the update and ping when it's ready.

[huzaifaalmesbah]

@jonathanbossenger @faisalahammad I pushed 5601aba. It restores includes/model/class-message.php and its tests to develop, so this PR now only has the Serde UTC fixes and the Factory\Message date deserialization. I updated the title and description, and changed "Closes #614" to "Part of #614" since the $meta_keys part is in #637.

Tests: 79 tests, 0 failures on single site and multisite. PHPCS is clean.

Since the scope changed after the approval, could you take another look, @jonathanbossenger?