Timezone and cron, a quiet footgun

Timezone and cron become a quiet problem when the server clock, cron, PHP, and WordPress each use a different zone. Cron follows the system timezone unless you set CRON_TZ on a supporting crontab. WordPress has its own display timezone, and PHP date.timezone is yet another setting. Keep the server on UTC, show local time in the app, and write ticket times in UTC so a “midnight” job does not land on evening traffic.

Work in this order so you do not surprise a live site. Confirm or set the OS timezone, restart cron so it rereads the zone, set WordPress to the human display zone, then set PHP on purpose in MultiPHP INI. Changing timezone on a mailbox can also change what Roundcube treats as “today,” so do that only when you mean to.

1. Read timedatectl and date -u so you know what the kernel thinks.
2. Set UTC on the server unless you have a documented reason not to.
3. Restart cron, or the systemd cron unit, after any timezone change.
4. Set WordPress under Settings → General to the timezone people expect to see.
5. Set PHP date.timezone in MultiPHP INI, not inside a plugin.

timedatectl; date -u

The first command shows the OS timezone name, NTP status, and local time. The second prints UTC so you can compare the offset. If they differ by the amount you expect, you are oriented. If they differ by three hours more than that, someone mixed a timezone change with a hardware clock left in local time. Do not stack offsets on top of each other.

Why a 00:00 job is not always local midnight

A crontab line like 0 0 * * * means midnight in cron’s timezone, not in the city you have in mind. If you assumed America/New_York while the OS stayed on UTC, that job ran at 19:00 or 20:00 Eastern and hit real traffic. On crontabs that support it, a line such as CRON_TZ=America/New_York above the schedule is the override. On cPanel, the account timezone in the panel can drive cron and may not match timedatectl, so check both before you trust the schedule.

The panel timezone is not a promise about the OS. Sometimes they match, and sometimes they do not. Read timedatectl, schedule the job, then watch one real run before you rely on it.

UTC on the server, local time in the app

Daylight saving is why UTC on the server is the calmer default. A job set for 01:30 local in March may run twice or not at all, depending on the zone rules. UTC plus a clear offset noted in the ticket avoids that argument. WordPress can still display America/New_York for readers. A job that charges cards or rotates logs should not depend on local wall time.

Shared hosting here uses cPanel without root, so you work with the panel timezone, MultiPHP INI, and your crontab rather than rewriting the whole OS. On a VPS you have root and can set the system zone with care, then restart cron and re-check the next fire. Either way, one documented clock for the server and one display zone for the app keeps support tickets short and jobs on time.

A short checklist before you leave the ticket

• Confirm timedatectl and date -u agree on the offset you expect.
• Confirm cron was restarted after any OS timezone change.
• Confirm WordPress Settings → General shows the human timezone only for display.
• Confirm PHP date.timezone in MultiPHP INI matches the plan you chose.
• Watch one scheduled run and note the fire time in UTC in the ticket.

If those five lines match, timezone stops being a footgun and becomes a boring, reliable setting.