So from the admin side, when you add a new customer, you do not get the ability to set the timezone of the customer. So then all the subsequent times in the booking process and the notifications, assume the customer is in UTC. For example, I added a customer, and I have Book in customers timezone turned OFF. But on the admin side, its showing the hours (and break) 4 hours ahead (which would be UTC). And when I choose a time like 5pm, the customer gets email saying 5pm but the agent (timezone is -4 UTC) sees 1pm.
In the screenshot, you see 3pm to 5pm is blocked out, but Todd's employee schedule is 11am to 1pm for blocked out times.
You will also see the difference in the times on the emails. I can't set the customers timezone. So that is REALLY confusing for the customer.
Unfortunately, currently, this feature is not built-in in Amelia. You can not set the time zone for customers. You can only set the zone for WordPress and for your employee, but you can not set the time zone for a customer. If you know in which time zone they are you can manually adjust that. So if they are 2 hours ahead of your employee you can book 2 hours ahead and that is it.
Features are pushed up on our "to-do" list when there are a lot of customers requesting those features, so having your vote as a customer can be beneficial to this feature being developed sooner.
If you have any more questions please open a new separate ticket for each question and we will gladly help you there.
Hi Marko. So I dont really need to set the timezone of the customer necessarily. However, there IS a bug. Please watch this video explaining the issue I'm running into
Can you please check what time zone is set for your WordPress? You have set the time zone for your employee but you can see it in your time zone and when he logs is to his panel he is seeing it in his time zone and customer can see it in his time zone if you have enable the option so that customer can see the time slot is in their time zone.
Amelia doesn't have any time zone settings, and it relies on WordPress' General settings. Here's how it works:
All times in the back-end of Amelia will be shown exactly how you save them, so (for example) if your employee works from 09:00 - 17:00, or if there's an appointment from 09:00 - 10:00, that's how you will see them in the back-end.
If you enable "Show booking slots in client time zone" in Amelia's General settings, though, that may not be what your customers see, depending on where they're located, and to what your WordPress site has been configured.
If this option in Amelia's General settings is disabled, all times on the front-end will be the same as times in the back-end. So, if your employee's work hours are from 09:00 - 17:00 in UTC+1, with this option disabled, regardless if your customer is in UTC+1, or in UTC+10 - they will still see times from 09:00 - 17:00, so if you have customers in multiple time zones, it's advisable to enable this option in Amelia's General Settings.
Important: In order for Amelia to store correct appointment times in the database (which is almost always in UTC time zone), you need to edit the WordPress' time zone to show the city you're in (or the city in your time zone), like this:
This way, when Daylight Savings Time starts (or ends), the times will be adjusted accordingly and you won't have to worry about them anymore.
If you save your Time Zone in UTC+/- format, you may experience issues with the Daylight Savings Time:
Explanation: When you configure the time zone to be "UTC+1" it will always be UTC+1. So, if we take Belgrade, Serbia as an example - without Daylight Savings Time, it is in UTC+1 time zone, but when Daylight Savings Time starts, Belgrade is in UTC+2. If you leave the time zone to be hard-coded to UTC+1, the times that your customers book on the front-end will not be properly adjusted to what you see in the back-end.
Example with UTC+1 configured: It is mid-summer, and Belgrade is in UTC+2. "Show booking slots in client time zone" is enabled, and a customer from Belgrade opens your website to book an appointment. The working hours of your employee are set from 09:00 - 17:00 (in UTC+1), but the customer sees them as 10:00 - 18:00. This is because the time zone is hard-coded in the back-end, while on the front-end it shows the time in UTC+2. So, a customer books an appointment for 10:00, and shows up at 10:00, while you expect to see them at 09:00.
Please note: If you hard-coded the time zone, and you have booked appointments, once you switch the time zone in WordPress to your city, it will adjust the times in Amelia's appointments to fit the time zone your city is currently in. This happens because (as mentioned above) the times are saved in UTC in the database, and it's adjusted in the plugin programmatically. So, if you have a hard-coded time zone set to UTC+1, and someone booked an appointment for 09:00, that time is saved as 08:00 in the database. When you change the time zone to your city (which is now in UTC+2), the appointment time will be adjusted to the time saved in the database 08:00 + 2:00, so the appointment time will switch to 10:00. The only solution, in this case, is to manually modify the appointment times, but it's the only way to make sure your time zone is properly configured, and that the future appointments will be saved and displayed correctly both for you and your customers on the front-end.
Summary: When you select the city you're in, in WordPress' General Settings, the system automatically calculates the Daylight Savings Time, and shifts the clock accordingly, so if you have any issues with what you see on the front-end vs what you see in the back-end, always check the Time Zone in WordPress.
So from the admin side, when you add a new customer, you do not get the ability to set the timezone of the customer. So then all the subsequent times in the booking process and the notifications, assume the customer is in UTC. For example, I added a customer, and I have Book in customers timezone turned OFF. But on the admin side, its showing the hours (and break) 4 hours ahead (which would be UTC). And when I choose a time like 5pm, the customer gets email saying 5pm but the agent (timezone is -4 UTC) sees 1pm.
In the screenshot, you see 3pm to 5pm is blocked out, but Todd's employee schedule is 11am to 1pm for blocked out times.
You will also see the difference in the times on the emails. I can't set the customers timezone. So that is REALLY confusing for the customer.
(HALO is the customer)
Attached files: Screenshot 2023-04-26 at 9.58.34 AM.png
Screenshot 2023-04-26 at 10.04.11 AM.png
Screenshot 2023-04-26 at 10.04.17 AM.png
Hello Steven,
Thank you for reaching out to us.
Unfortunately, currently, this feature is not built-in in Amelia. You can not set the time zone for customers. You can only set the zone for WordPress and for your employee, but you can not set the time zone for a customer. If you know in which time zone they are you can manually adjust that. So if they are 2 hours ahead of your employee you can book 2 hours ahead and that is it.
I'll kindly ask you to add it as a feature suggestion on this link https://features.wpamelia.com/
Features are pushed up on our "to-do" list when there are a lot of customers requesting those features, so having your vote as a customer can be beneficial to this feature being developed sooner.
If you have any more questions please open a new separate ticket for each question and we will gladly help you there.
We wish you all the best.
Have a nice day.
Kind Regards,
Marko Davidovic [email protected]
Rate my support
Try our FREE mapping plugin! MapSVG - easy Google maps, interactive SVG maps, floor plans, choropleth maps, and much more - https://wordpress.org/plugins/mapsvg-lite-interactive-vector-maps/
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables
Hi Marko. So I dont really need to set the timezone of the customer necessarily. However, there IS a bug. Please watch this video explaining the issue I'm running into
https://u.pcloud.link/publink/show?code=XZyovqVZuOOSIXz3XrpHnpb71BNuoSYlIvcy
Hello Steven,
Can you please check what time zone is set for your WordPress? You have set the time zone for your employee but you can see it in your time zone and when he logs is to his panel he is seeing it in his time zone and customer can see it in his time zone if you have enable the option so that customer can see the time slot is in their time zone.
Amelia doesn't have any time zone settings, and it relies on WordPress' General settings. Here's how it works:
All times in the back-end of Amelia will be shown exactly how you save them, so (for example) if your employee works from 09:00 - 17:00, or if there's an appointment from 09:00 - 10:00, that's how you will see them in the back-end.
If you enable "Show booking slots in client time zone" in Amelia's General settings, though, that may not be what your customers see, depending on where they're located, and to what your WordPress site has been configured.
If this option in Amelia's General settings is disabled, all times on the front-end will be the same as times in the back-end. So, if your employee's work hours are from 09:00 - 17:00 in UTC+1, with this option disabled, regardless if your customer is in UTC+1, or in UTC+10 - they will still see times from 09:00 - 17:00, so if you have customers in multiple time zones, it's advisable to enable this option in Amelia's General Settings.
Important: In order for Amelia to store correct appointment times in the database (which is almost always in UTC time zone), you need to edit the WordPress' time zone to show the city you're in (or the city in your time zone), like this:
This way, when Daylight Savings Time starts (or ends), the times will be adjusted accordingly and you won't have to worry about them anymore.
If you save your Time Zone in UTC+/- format, you may experience issues with the Daylight Savings Time:
Explanation: When you configure the time zone to be "UTC+1" it will always be UTC+1. So, if we take Belgrade, Serbia as an example - without Daylight Savings Time, it is in UTC+1 time zone, but when Daylight Savings Time starts, Belgrade is in UTC+2. If you leave the time zone to be hard-coded to UTC+1, the times that your customers book on the front-end will not be properly adjusted to what you see in the back-end.
Example with UTC+1 configured: It is mid-summer, and Belgrade is in UTC+2. "Show booking slots in client time zone" is enabled, and a customer from Belgrade opens your website to book an appointment. The working hours of your employee are set from 09:00 - 17:00 (in UTC+1), but the customer sees them as 10:00 - 18:00. This is because the time zone is hard-coded in the back-end, while on the front-end it shows the time in UTC+2. So, a customer books an appointment for 10:00, and shows up at 10:00, while you expect to see them at 09:00.
Please note: If you hard-coded the time zone, and you have booked appointments, once you switch the time zone in WordPress to your city, it will adjust the times in Amelia's appointments to fit the time zone your city is currently in. This happens because (as mentioned above) the times are saved in UTC in the database, and it's adjusted in the plugin programmatically. So, if you have a hard-coded time zone set to UTC+1, and someone booked an appointment for 09:00, that time is saved as 08:00 in the database. When you change the time zone to your city (which is now in UTC+2), the appointment time will be adjusted to the time saved in the database 08:00 + 2:00, so the appointment time will switch to 10:00. The only solution, in this case, is to manually modify the appointment times, but it's the only way to make sure your time zone is properly configured, and that the future appointments will be saved and displayed correctly both for you and your customers on the front-end.
Summary: When you select the city you're in, in WordPress' General Settings, the system automatically calculates the Daylight Savings Time, and shifts the clock accordingly, so if you have any issues with what you see on the front-end vs what you see in the back-end, always check the Time Zone in WordPress.
Hope this explains it.
Kind Regards,
Marko Davidovic [email protected]
Rate my support
Try our FREE mapping plugin! MapSVG - easy Google maps, interactive SVG maps, floor plans, choropleth maps, and much more - https://wordpress.org/plugins/mapsvg-lite-interactive-vector-maps/
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables