Amelia doesn’t offer its own time zone settings—it relies entirely on the General Settings configured in your WordPress site.
Any times you define in the Amelia back-end will appear exactly as you've entered them. For instance, if an employee’s working hours are set from 09:00 to 17:00, or there's an appointment scheduled from 09:00 to 10:00, those times will be shown as-is on the admin side.
However, if you enable the option “Show booking slots in client time zone” (found in Amelia → Settings → General), the times displayed to your customers might differ depending on their local time zones and the settings of your WordPress site.
If that setting is disabled, then front-end users will see the exact same times as those set in the back-end—regardless of their actual time zone. So if your site is set to UTC+1, a customer in UTC+10 would still see availability from 09:00 to 17:00.
This is why enabling this setting is recommended if your services are available across different time zones.
Setting the Correct Time Zone in WordPress
In order for Amelia to store and display appointment times accurately (since it stores them in UTC format in the database), you should configure your site’s time zone in WordPress using a city name (e.g. “Belgrade” or “New York”) instead of a static offset like “UTC+1”.
Here’s how that should look:
(This is where you'd insert a screenshot of the WordPress time zone setting using a city)
By choosing a city-based time zone in your WordPress settings, your website will automatically adjust for Daylight Saving Time changes. That means when the clocks move forward or back, Amelia will stay in sync—no extra work needed on your end.
On the other hand, if you use a manual UTC offset (like “UTC+1”), your site won’t account for daylight saving changes. This can cause discrepancies between the time your customers see and the actual appointment time stored in the system.
Why choosing the right time zone matters
If you manually set your time zone in WordPress to a fixed offset like “UTC+1”, it will always follow that offset—regardless of whether Daylight Saving Time (DST) is in effect.
Let’s say you’re in Belgrade, Serbia. In winter, Belgrade operates on UTC+1, but in summer, it shifts to UTC+2 due to DST. If your site is locked to UTC+1, Amelia will still display appointment times using that offset—even when the local time has changed.
Here’s how that affects bookings:
Imagine your employee’s working hours are set from 09:00 to 17:00, and DST is active (Belgrade is now UTC+2). If “Show booking slots in client time zone” is enabled, customers in Belgrade will see those working hours as 10:00 to 18:00. So, if someone books for 10:00, they’ll show up at what they believe is the correct time—while you’re expecting them at 09:00.
Important note:
If you've been using a fixed UTC offset and then switch to a city-based time zone in WordPress, appointment times already booked may be automatically adjusted. This happens because Amelia stores appointment times in UTC in the database.
For example, an appointment booked at 09:00 under UTC+1 is stored as 08:00 in the database. If you later change the time zone to a city currently in UTC+2, Amelia will display that appointment as 10:00 (08:00 UTC + 2 hours). If you need to keep those original times, you’ll have to manually adjust them.
In summary:
Setting your time zone to a specific city (instead of a fixed UTC offset) ensures WordPress and Amelia handle Daylight Saving Time correctly. If appointment times ever seem off on the front-end compared to the back-end, double-check your WordPress time zone settings first.