A custom date field to show the same value on Overviews as the date selected within a ticket field.
Actual behavior:
The values of date fields displayed on Overviews are affected by browser timezone.
Steps to reproduce the behavior:
Create a new ticket object of type “date field”.
Set a date within the field on a ticket.
Add the field as a column on an Overview.
Change the browser timezone and the value displayed can change.
Hi,
As described above we have added a custom date field to tickets (not datetime, just date) and when selecting/viewing these dates within a ticket field everything is correct. When viewing the value of the date field from Overviews though the date is always 1 day earlier as the value is affected by the timezone of the browser.
Our PCs, Zammad’s branding timezone, and the underlying server OS are all configured for GMT-7 timezone. If I set my PC timezone to GMT-2 or any other timezone 5+ hours ahead of GMT-7 then the value of the date field on the Overview is correct and matches the actual value selected in the field.
I’m assuming this a bug? Is there any possible workaround?
All times in Zammad are stored in UTC - this allows Zammad to always display the same time (technically) to the user, depending on their local timezone. A pending ticket for example thus always pops up at the designated moment for all agents. Other wise a GMT-6 timing would hit 7 hours ‘early’ on a GMT+1 client.
For my instance I have solved the issue, thanks to @MrGeneration, I have changed the timezone under Settings > Branding to UTC (GMT+0), but left my PC and the Server to CST (GMT-6), everything is being displayed correctly now, well its being displayed the way I want it to be displayed.
The main issue is that the value changes for the same user depending on where the field is viewed. When the date is viewed as a field in a ticket, it is correct. When the date is viewed from an overview, it is different. The value is affected by time zone only when displayed on Overviews.
I personally don’t see a reason why a time zone should affect a date object at all. I completely understand why a datetime would be adjusted by time zone as it actually has a time of day associated to it, but I think if you have a field set to January 1st it should show as January 1st regardless of the user’s time zone.
Because an appointment on the 1st January on 8am is a different moment to me in Berlin than someone in Washington DC. International working with Zammad around the globe in a team wouldn’t be possible with the way you’d want it to work.
The consequence would be to always display the timezone in question and let the user do the math. That’s not really user friendly.
If you find inconsistencies in between Zammads UI parts in terms of “one place displays UTC and the other the correct local timezoned time” then this would be a bug and should be reported.
Apart from that, as mentioned above, the behavior is technically correct and working as designed.
Sorry if I wasn’t clear, but I was trying to report an inconsistency in the UI. The value of the custom date field differed for the same user when viewing the field within the ticket and from an Overview. The timezone seemed to only be applied to the value on one page and not the other.
I just tested again today though and the issue seems to be resolved now. It looks like either the Zammad 6.4.0 or 6.4.1 update fixed whatever the underlying issue was.