Wrong times on bookings and emails come from settings in different time zones. Set WordPress to your city rather than a fixed UTC offset, match every plugin and service to it, then test a real booking.

Booked for six, confirmed for five

A customer books a six o'clock appointment on a website. The confirmation email says five, and so does the reminder the day before.

Or a blog post scheduled for nine in the morning goes out in the middle of the night, and order emails carry times seven hours ahead of the clock on the wall.

Nothing is broken in the usual sense. Somewhere between the server, the website and the booking system, one setting is in a different time zone from the others.

Vancouver is currently seven hours behind Coordinated Universal Time, or UTC, the reference clock many servers use. In November it will be eight, and that hour is where most of these problems hide.

Where the time comes from

The third is where mismatches usually hide. A booking plugin set to Vancouver on a site set to something else will agree on some screens and not others, depending on which setting each part reads.

WordPress keeps its own clock

Under Settings, then General, WordPress has a Timezone menu. It offers two kinds of choice: a city, such as Vancouver, or a fixed offset from UTC, such as UTC-8.

They look interchangeable and are not. A city follows that place's clock changes, so a site set to Vancouver moves with daylight saving time.

A fixed offset never moves. UTC-8 is right in winter and an hour out from March to November.

With a city chosen, the screen shows the local time and the date standard time next begins, November 4 for Vancouver this year. New sites often start at UTC+0 until somebody changes it.

Choosing the right city

Pick the listed city that shares your clock all year, not just your offset today. Most of BC chooses Vancouver; the East Kootenays, on Mountain time, choose Edmonton.

A few places in BC never change their clocks, including Creston and Dawson Creek, and the list includes both. A business there set to Vancouver or Edmonton would be an hour out for part of every year.

Plugins and services with clocks of their own

Booking systems usually have a time zone in the account settings, and sometimes another for each staff member or resource. Calendars they sync with, such as Google Calendar, have their own as well.

Email platforms usually schedule newsletters in the account's time zone. Analytics splits each day at midnight in the time zone set for each view, which decides the day a late order counts on.

The server's own clock matters less than people expect, since WordPress and most services convert times themselves. It matters when a plugin asks the server directly.

The time zone the customer sees

Some booking widgets show slots in the visitor's own time zone, taken from their phone or computer. For a video call, that helps.

For an appointment in person, it means somebody planning a trip from Calgary sees seven o'clock for a slot that is six o'clock at your door.

So for in-person bookings, show your own time zone and say so on the page: all times Pacific.

In confirmations, write the date in words with the zone, such as Wednesday, August 8, 6:00 p.m. Pacific, and nobody has to convert anything.

A worked example

An indoor tennis centre takes court bookings through a plugin on its WordPress site. Players book an hour and get a confirmation by email, then a reminder the day before.

The site launched in February. Whoever set it up chose UTC-8 in General Settings, which was correct at the time, and set the plugin's own time zone to Vancouver.

On March 11 the clocks went forward. The booking calendar, using the plugin's setting, kept showing the right times. The emails, which took their times from WordPress, began showing every booking an hour early.

Regulars ignored the emails. Newer players believed them, arrived an hour early and found their court in use, and the front desk put it down to misreading.

It came to light when a player forwarded her confirmation with a polite question. General Settings now says Vancouver, every email states the time zone, and a test booking is in the calendar for November.

Scheduled posts and timed tasks

Scheduled posts publish by WordPress's own clock. One scheduled for 9 a.m. on a site left at UTC+0 goes out at 2 a.m. in Vancouver this summer.

Most timed tasks in WordPress, such as reminder emails, also wait for somebody to visit the site before they run, so on a quiet site a task due at eight may run at a quarter past.

Where timing matters, a proper timer on the server can run those tasks on schedule. Whoever looks after the site can arrange it in minutes.

Testing with a real booking

Settings pages show what each part is set to. Only a booking shows what the customer sees.

Book a real slot at a time that is easy to recognise, such as 4:15 in the afternoon, and follow it everywhere: the screen after booking, both emails, the staff calendar and the dashboard.

Do it again the week after each clock change, after any move to a new server, and after updating the booking plugin. Those are the moments a hidden mismatch shows itself.

The counter-case

A site with no bookings, no shop and no scheduled posts has little riding on its time zone. A wrong setting there is a small tidy-up.

A booking system run entirely by an outside service, with nothing generated by the website, has one setting to check rather than several.

Even then, the check takes a minute, and the clocks change twice a year.

Wherever times reach customers: set every clock to your city, then prove it with a test booking.

The check

  1. Open General Settings in WordPress.
  2. Choose your city, not a UTC offset.
  3. Check each plugin that has its own time zone.
  4. Match outside services and calendars to it.
  5. Make a test booking at a memorable time.
  6. Read every email and calendar entry it creates.
  7. Repeat the test after November 4.

Step five is the only one that shows what customers see. Settings can each look right and still disagree, and a booking followed from start to finish finds the disagreement in minutes.

Leftovers from old plugins cause a different kind of quiet error, covered in shortcodes left behind by an old page builder.

Frequently asked questions

Why do booking emails show the wrong time?

Usually because the booking system and WordPress are set to different time zones, or one uses a fixed offset that ignores daylight saving time. Each part converts times its own way.

Should WordPress use a city or a UTC offset?

A city. One such as Vancouver follows daylight saving time automatically, while a fixed offset like UTC-8 never moves and is an hour wrong for most of the year.

Where is the WordPress time zone setting?

Under Settings, then General, in the Timezone menu. With a city chosen, the screen shows the local time and the date the next clock change takes effect.

Does the server's time zone matter?

Less than people expect, since WordPress and most services convert times themselves. It matters when a plugin reads the server's clock directly or a task runs at a fixed hour.

Which time zone should customers see?

For appointments in person, the business's own, stated on the page and in every confirmation with the date in words. The visitor's own time zone suits video calls.

When should bookings be tested again?

The week after each clock change, after moving to a new server, and after updating the booking plugin. Those are the moments hidden mismatches appear.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Confirmations showing the wrong time?

Send us the link to your booking page. We will trace which setting is out and put every clock on the same time.

Start a Conversation