For a WordPress website that follows a local business clock, choose a city with the same timezone rules in Settings > General > Timezone. A fixed UTC offset can match today and be wrong after daylight saving changes. If your business deliberately schedules everything in UTC, keeping UTC may be the correct choice instead.
The important distinction is the rule you want the site to follow, not where its server is located. Before changing a live website, check scheduled content and any plugins that send messages, take bookings or run time-sensitive jobs. Correcting the site clock is not proof that every connected service now agrees.
A city follows regional rules; an offset stays fixed
A named timezone, such as Europe/London, identifies a region’s time rules. A numeric offset, such as UTC+1, describes a fixed difference from UTC. They can show the same hour on one date without being interchangeable throughout the year.
WordPress’s timezone implementation uses the saved timezone name when one exists, otherwise a numeric offset. Its site timezone function turns that selection into a timezone object used by WordPress date functions. This is why changing a date’s display format cannot supply the missing regional rule.
Choose a city in the same timezone jurisdiction as the business, not simply the geographically closest city. Nearby regions can follow different clock rules. A business with customers around the world still needs an explicit operational timezone; a single WordPress setting cannot communicate every customer’s local appointment time.
A worked example: London and UTC+1
Consider a hypothetical London business that wants to publish at 09:00 local time. Under the 2026 timezone rules, these two dates illustrate the difference. The conversions were checked using PHP timezone calculations; they are not a test of publishing or a client website.
| Setting and date | 09:00 means in UTC | Meaning for the business |
|---|---|---|
| London, 15 July 2026 | 08:00 UTC | The regional clock is one hour ahead of UTC. |
| London, 15 January 2026 | 09:00 UTC | The regional clock matches UTC. |
| Fixed UTC+1, either date | 08:00 UTC | The offset stays the same, including when London’s clock does not. |
A fixed UTC+1 selection therefore matches this business’s summer clock but not its winter clock. The lesson is not to copy London into every website. It is to match your own business’s regional rules, or deliberately document why the site uses a fixed reference time.
Check the native WordPress timezone setting
The official General Settings guide documents the timezone selector. On a self-hosted WordPress site, use the following sequence:
- Sign in to the site’s own WordPress dashboard with permission to manage settings, then open Settings > General.
- Find Timezone. Record the current selection before editing. Compare the displayed Universal time and Local time with a trusted clock.
- Decide whether the site should follow a regional business clock or a deliberately fixed UTC reference. Check the schedules below before saving a different choice.
- If a change is approved, select the matching city or intended UTC offset. Leave the other General Settings fields unchanged and click Save Changes.
- Reopen the screen and confirm the saved choice and displayed local time. Check any daylight-saving information shown for the selected region.
The Date Format and Time Format controls affect presentation. They are not substitutes for choosing the correct timezone. Do not change the site’s address, registration policy or administrator email while troubleshooting a clock difference.
If the control is unavailable, ask the person responsible for the site’s configuration to inspect it. Do not install a timezone plugin or edit database values just to bypass an access limitation.
Before saving, identify what could change
Start with the next scheduled post. In Posts > All Posts, open the scheduled item and inspect its saved publication date and time. Write down the intended deadline with its timezone, for example, “09:00 London time”, rather than “nine tomorrow”.
Do not assume existing scheduled entries will automatically be rebuilt as you intend after a global setting changes. Compare their displayed schedule before and after the change. If a campaign has an imminent deadline, agree the publication plan with its owner before saving anything.
Then list the other clocks involved. A backup plugin, booking extension, hosting scheduler and external email platform may each have their own scheduling or display behavior. Inspect the owning product’s settings and documentation. A server log stamped in UTC is not wrong merely because WordPress displays local time.
For a trading store, preserve current orders and bookings. Do not restore an old database just to reverse a clock setting. If the change affects confirmations, availability or an important deadline, stop further edits, retain the observed results and involve the person who owns that workflow.
Why a correct timezone may not fix a late task
A task can be scheduled correctly and still start late. WordPress’s event scheduler works with UTC timestamps; its default execution depends on a suitable visit after an event becomes due. A missing trigger or failing callback is a different problem from choosing the wrong local clock.
There is another distinction: every 24 hours is not necessarily the same local hour every day. The built-in daily recurrence is an interval of 86,400 seconds. Across a daylight-saving transition, the local time displayed for a fixed-interval sequence can move by an hour. Plugins can implement their own scheduling logic, so inspect the actual task rather than assuming every “daily” label works identically.
If one recurring task shifts while the site clock remains correct, investigate that task’s recurrence. If unrelated jobs all become overdue, use the WordPress cron diagnosis guide. Repeatedly adjusting the global timezone can hide the symptom while changing other schedules.
Verify the result without triggering customer actions
Use an isolated staging site for a scheduling rehearsal. Keep outbound customer email, payment and live calendar connections isolated. Schedule harmless test content, record its intended time in both the chosen local zone and UTC, then observe its actual publication and public URL. A manual Publish click does not test automatic scheduling.
On production, first use read-only checks: the saved setting, upcoming post times and the next expected run shown by the affected plugin. Agree any live test with the responsible owner. Check the business result, not only a changed timestamp: a completed backup must reach its destination, and a booking confirmation must describe the agreed appointment.
If the clock becomes incorrect after your change, restore the recorded timezone selection and inspect affected schedules again. Restoring the setting does not undo emails already sent, appointments accepted or content already published. Reconcile those effects separately before attempting another change.
Webless’s WordPress maintenance service is the relevant route for checking routine scheduling and its evidence. A custom integration that interprets time differently may require development. Describe which task is wrong, the expected timezone and one anonymized example so the investigation starts at the right layer.