Hello there, I have noticed a bug in the events section of the plugin. If you book the tour in the URL I have provided, the employee email has the wrong time on it. The customer email is correct with a starting time of 8pm, but the staff email says 9pm. I have made test bookings on some of the other tours I offer and the problem seems to be specific to this one, is this a known bug?
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 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 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.
Hello there, I'm afraid that these are my settings and my problem persists. I have my timezone set to Dublin. Now this problem is occurring in both my customer and staff emails. I have had customers turn up an hour late for a tour and missed it. Some of my test bookings reproduce this problem and some don't which is why I think it's a bug or something to do with the customers being from other countries. I can guarantee you that my settings in Wordpress are for Dublin, and that I have not enabled 'show booking slots in client timezone' so what else could this be? I need this problem addressed asap Thanks very much in advance Dan
Please provide me a temporary WP-admin (administrator) user for your site where this happens, so we could log in and take a look ‘from the inside’ as that’s the most efficient way to see and resolve the issue.
We do not interfere with any data or anything else except for the plugin (in case that’s a production version of the site), and of course, we do not provide login data to third parties.
You can write credentials here just check PRIVATE Reply so nobody can see them except us.
Amelia stores all bookings in your server time zone, which is usually set to UTC. Based on your current configuration, regardless of the customer's time zone, your appointments and or event time slots will appear in your time, so if an event is scheduled for 08:00, it will show as 08:00 in Dublin and in Tokyo.
If you enable the "Show booking slots in client time zone", the bookings are still stored in your database's (server) time zone and converted based on the client's physical location.
Do you have examples of previous emails/events that I can check?
Remember to enable the Private response so no sensitive details are shared with the public.
Is there a solution to this issue? As I have the same thing happening but the other way round. Staff received email with correct start time of 9.30am and customer received email with incorrect start time of 10.30am. Both staff and customer are on UK time.
Hello there, I have noticed a bug in the events section of the plugin. If you book the tour in the URL I have provided, the employee email has the wrong time on it. The customer email is correct with a starting time of 8pm, but the staff email says 9pm. I have made test bookings on some of the other tours I offer and the problem seems to be specific to this one, is this a known bug?
Hello Daniel,
Thank you for reaching out to us.
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 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 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.
Kind Regards,
Uros Jovanovic
[email protected]
Rate my support
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
Hello there,
I'm afraid that these are my settings and my problem persists. I have my timezone set to Dublin. Now this problem is occurring in both my customer and staff emails. I have had customers turn up an hour late for a tour and missed it. Some of my test bookings reproduce this problem and some don't which is why I think it's a bug or something to do with the customers being from other countries. I can guarantee you that my settings in Wordpress are for Dublin, and that I have not enabled 'show booking slots in client timezone' so what else could this be? I need this problem addressed asap
Thanks very much in advance
Dan
Hello Daniel,
Thank you for the update on this.
Please provide me a temporary WP-admin (administrator) user for your site where this happens, so we could log in and take a look ‘from the inside’ as that’s the most efficient way to see and resolve the issue.
We do not interfere with any data or anything else except for the plugin (in case that’s a production version of the site), and of course, we do not provide login data to third parties.
You can write credentials here just check PRIVATE Reply so nobody can see them except us.
Kind Regards,
Uros Jovanovic
[email protected]
Rate my support
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
Hello Daniel
Amelia stores all bookings in your server time zone, which is usually set to UTC. Based on your current configuration, regardless of the customer's time zone, your appointments and or event time slots will appear in your time, so if an event is scheduled for 08:00, it will show as 08:00 in Dublin and in Tokyo.
If you enable the "Show booking slots in client time zone", the bookings are still stored in your database's (server) time zone and converted based on the client's physical location.
Do you have examples of previous emails/events that I can check?
Remember to enable the Private response so no sensitive details are shared with the public.
Kind Regards,
Aleksandar Vuković
[email protected]
Rate my support
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
Is there a solution to this issue? As I have the same thing happening but the other way round. Staff received email with correct start time of 9.30am and customer received email with incorrect start time of 10.30am. Both staff and customer are on UK time.
Thanks,
Karen
Attached files: Screenshot 2024-09-25 at 13.08.20.png
Screenshot 2024-09-25 at 13.08.30.png
Hello Karen,
Thank you for reaching out to us.
Can you please create a separate ticket for this purpose and we will take a look into this and let you know what the issue is?
Just paste the ticket link here so we can respond as soon as possible.
Looking forward to your reply.
Kind Regards,
Uros Jovanovic
[email protected]
Rate my support
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
Now on a separate ticket: https://tmsplugins.ticksy.com/ticket/3732995
Hello Karen,
We will respond to this ticket as soon as possible.
I appreciate your patience.
Kind Regards,
Uros Jovanovic
[email protected]
Rate my support
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