We updated Amelia from 7.7.1 to 7.8.0 last night and now some staff see appointments one hour out, and others do not.
For example, my account sees the first appointment at 9am, but jane@ sees it at 8am. See screenshots.
If I log into jane@ on my computer, I see the time wrong, too. So it is the user's account that is causing the error, not the server, WordPress settings or their computer.
I've tried changing the WordPress timezone in general settings to something else, and the times of all the appointments on my account change as expected. However, this has no effect on Jane's account, and the times remain unchanged and wrong.
I've tried changing the users timezone in the employee settings of Amelia, but this doesn't do anything.
I've now rolled the version back to 7.7.1 and everything is OK.
Please tell me what is wrong so that next time we update, this doesn't happen again.
There was not changes with any of such optopin in update so this should not be related to this.
Check the time zone that is set in WordPress
Check the time zone for employees in employee modal this can be causing the issues
Amelia check the time zone that is set on customer device
Also this can be due to a daylight saving.
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.
One of these should help.
We wish you all the best and hope you have a wonderful day ahead.
Thank you for your response, but I believe there may be a misunderstanding. The issue seems to stem from the plugin update itself, not from our setup or time zone configurations.
As mentioned, after updating Amelia from 7.7.1 to 7.8.0, some staff accounts are showing appointments one hour out, while others are not. This discrepancy persists even after adjusting the WordPress time zone and Amelia employee settings, which suggests the issue is account-specific rather than related to the server or system settings.
We’ve now updated to version 7.8.2, the latest release, and the issue still persists. Rolling back to version 7.7.1 resolves the issue entirely, so it seems the problem is introduced in the newer versions of Amelia. Could you please investigate whether there were any changes in the handling of time zones or appointment display logic in these updates? It does not appear to be linked to daylight saving or our general setup, as the issue only arises post-update.
Looking forward to your clarification and guidance on this.
With latest version we have some time zone issues where employees see the appointment in UTC time zone they can show 2 hours earlier in most cases. But since your issue predates this it should not be related. But in any case our dev is working on it already and it should be released in on of the future updates most likely in the next one. Which hopefully it will be soon. Once new update is available please update Amelia purge the cache and let us know if the issue is resolved on your end.
We wish you all the best and hope you have a wonderful day ahead.
Please do not write on other users ticket since they will get your question and our reply and some users do not want that and policy is to not disturb other users.
Our dev team is working on it already they will do their best to implement fix in Amelia as soon as it it technically possible.
We wish you all the best and hope you have a wonderful day ahead.
We updated Amelia from 7.7.1 to 7.8.0 last night and now some staff see appointments one hour out, and others do not.
For example, my account sees the first appointment at 9am, but jane@ sees it at 8am. See screenshots.
If I log into jane@ on my computer, I see the time wrong, too. So it is the user's account that is causing the error, not the server, WordPress settings or their computer.
I've tried changing the WordPress timezone in general settings to something else, and the times of all the appointments on my account change as expected. However, this has no effect on Jane's account, and the times remain unchanged and wrong.
I've tried changing the users timezone in the employee settings of Amelia, but this doesn't do anything.
I've now rolled the version back to 7.7.1 and everything is OK.
Please tell me what is wrong so that next time we update, this doesn't happen again.
Hello there,
Thank you for reaching out to us.
There was not changes with any of such optopin in update so this should not be related to this.
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.
We wish you all the best and hope you have a wonderful day ahead.One of these should help.
Kind Regards,
Marko Davidovic
[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 Marko,
Thank you for your response, but I believe there may be a misunderstanding. The issue seems to stem from the plugin update itself, not from our setup or time zone configurations.
As mentioned, after updating Amelia from 7.7.1 to 7.8.0, some staff accounts are showing appointments one hour out, while others are not. This discrepancy persists even after adjusting the WordPress time zone and Amelia employee settings, which suggests the issue is account-specific rather than related to the server or system settings.
We’ve now updated to version 7.8.2, the latest release, and the issue still persists. Rolling back to version 7.7.1 resolves the issue entirely, so it seems the problem is introduced in the newer versions of Amelia. Could you please investigate whether there were any changes in the handling of time zones or appointment display logic in these updates? It does not appear to be linked to daylight saving or our general setup, as the issue only arises post-update.
Looking forward to your clarification and guidance on this.
Hello again,
With latest version we have some time zone issues where employees see the appointment in UTC time zone they can show 2 hours earlier in most cases. But since your issue predates this it should not be related. But in any case our dev is working on it already and it should be released in on of the future updates most likely in the next one. Which hopefully it will be soon. Once new update is available please update Amelia purge the cache and let us know if the issue is resolved on your end.
We wish you all the best and hope you have a wonderful day ahead.
Kind Regards,
Marko Davidovic
[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
we are experiencing the same issue and this has caused major issues for us today - can this be resolved quickly?
Hello again,
Please do not write on other users ticket since they will get your question and our reply and some users do not want that and policy is to not disturb other users.
Our dev team is working on it already they will do their best to implement fix in Amelia as soon as it it technically possible.
We wish you all the best and hope you have a wonderful day ahead.
Kind Regards,
Marko Davidovic
[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