Site Timezone vs Server Timezone: Why They Must Match

1 min read

Overview #

WordPress stores dates in its own timezone setting, but PHP scripts (and the server) run in the server timezone. When the two differ, timestamps stop lining up: posts publish at the wrong time, scheduled actions fire early or late, and support logs become confusing. The fix is making the server timezone match the site.

The Alert #

SITE_SERVER_TIMEZONE (warning): the WordPress site timezone differs from the server’s PHP timezone. Date handling will be inconsistent until both match.

Why It Matters #

Symptom What’s happening
Posts publish at the wrong time WordPress schedules by site timezone, but PHP stamps events in server time
Scheduled actions fire early/late Action Scheduler, FluentCRM sequences, and WooCommerce renewals rely on consistent clocks
Order times look wrong WooCommerce order timestamps inherit the server timezone
Logs don’t match reality Error logs, backups, and uptime events are stamped in server time

The Fix #

Set the PHP timezone to match the site, both to the client’s local zone.

  • GridPane: control panel → PHP settings → Date Timezone, set to the site’s zone (Xponent does this for you).
  • php.ini / .user.ini: date.timezone = Africa/Johannesburg (or the client’s zone).

Verifying the Change #

Check WordPress admin → Settings → General → Timezone and confirm the site’s zone, then confirm the server value via the GridPane panel. Both must show the same zone.

The Xponent Standard #

All Xponent-managed sites have the server timezone set to the client’s local zone at provisioning. Dates, schedules, and logs all speak the same time, and the alert stays clear.

Related Articles #

Updated on August 31, 2026