For an API-scheduled post, we would store one intended instant and derive the site-local and UTC values from it. Then we would read the saved post back. A request accepted by WordPress is useful evidence, but the returned date fields and status tell you what was actually scheduled.
Read the three fields together
The WordPress posts schema defines date in the site’s timezone and date_gmt in GMT. Status is separate, with future and publish among its allowed values. Modified timestamps are separate again. Do not use modified or modified_gmt as publication scheduling fields.
| Field | Meaning | Common mistake |
|---|---|---|
| date | Publication date in the site timezone | Sending a UTC clock reading as if it were site-local time |
| date_gmt | The corresponding publication instant in GMT/UTC | Calculating it with the wrong seasonal offset |
| status | Requested post state, such as future | Assuming a future-looking string alone proves scheduled status |
Use the named timezone for the target date
A named timezone such as America/New_York contains daylight-saving rules. A fixed UTC offset does not. When a site uses seasonal clock changes, derive the offset for the publication date, not the day the API request is written. Around a clock change, some local times are skipped or occur twice. Make that ambiguity explicit in your scheduler instead of accepting whichever interpretation a date library chooses.
Here is an illustrative scheduling body for a WordPress site configured to America/New_York. On November 20, 2026, 9:00 AM there corresponds to 14:00 UTC. The two fields express the same instant. The example contains no credentials and is not a request to publish a real post.
{
"title": "Illustrative scheduled article",
"status": "future",
"date": "2026-11-20T09:00:00",
"date_gmt": "2026-11-20T14:00:00"
}If your integration sends both date fields, calculate them together and reject an inconsistent pair before sending it. Do not depend on undocumented precedence between conflicting values. If the intended instant has already passed by the time the request is sent, handle it as an overdue publication decision rather than assuming the CMS will preserve the original future state.
Read the post back by its saved ID
- Save the returned post ID and intended publication instant with the job.
- Retrieve that same post and compare status, date and date_gmt with the intended values.
- Confirm the site timezone used for the conversion. Do not substitute the browser’s local zone.
- At the deadline, verify published status and the expected public body. If the response was lost, recover the existing post by identity before creating another one.
A correct timestamp still needs execution
WordPress uses WP-Cron for scheduled publication, and its default trigger checks due work on page loads. A correct future post can therefore still be late if the execution path is not working. Inspect the actual cron trigger and errors separately from the timezone calculation.
After changing the site timezone, audit pending posts
Read each pending post’s saved local and UTC values and compare them with the business’s intended instant. Decide whether a schedule means a fixed global instant or a fixed local appointment. Those are different requirements after a timezone change. Correct the existing post by ID only after resolving that intent, then verify it again. Avoid rewriting an already published article’s original publication date as a side effect of a content update.
The useful invariant is simple: the stored instant, the site-local representation and WordPress’s saved state agree. Test a normal date and dates around the site’s clock changes, then verify actual publication through the same integration.
