That’s odd.
This time in history is in UTC, if I could verify this correct, you’ll have UTC time minus 2 hours (if you use Berlin as timezone, might be worse on yours).
Could you please let us know how huge your difference is?
Hello sorry for the late response.
Our OS time zone is set to UTC and Our Zammad Application Time is Set to Asia/Manila (GMT+8).
Can you advise what’s the best approach in order for us to generate the report that is set to Asia/Manila (GMT+8) time zone. Thanks in advance!
Heya,
by now we found this to be a bug, you can check it out here:
opened 04:54AM - 17 Jun 18 UTC
closed 01:39PM - 28 Apr 20 UTC
duplicate
<!--
Hi there - thanks for filing an issue. Please ensure the following things … before creating an issue - thank you! 🤓
Since november 15th we handle all requests, except real bugs, at our community board.
Full explanation: https://community.zammad.org/t/major-change-regarding-github-issues-community-board/21
Please post:
- Feature requests
- Development questions
- Technical questions
on the board -> https://community.zammad.org !
If you think you hit a bug, please continue:
- Search existing issues and the CHANGELOG.md for your issue - there might be a solution already
- Make sure to use the latest version of Zammad if possible
- Add the `log/production.log` file from your system. Attention: Make sure no confidential data is in it!
- Please write the issue in english
- Don't remove the template - otherwise we will close the issue without further comments
- Ask questions about Zammad configuration and usage at our mailinglist. See: https://zammad.org/participate
Note: We always do our best. Unfortunately, sometimes there are too many requests and we can't handle everything at once. If you want to prioritize/escalate your issue, you can do so by means of a support contract (see https://zammad.com/pricing#selfhosted).
* The upper textblock will be removed automatically when you submit your issue *
-->
### Infos:
* Used Zammad version: 2.5
* Installation method (source, package, ..): zammad-docker-compose
* Ticket-ID: #1049736
### Expected behavior:
* zammad handles servers running in a different timezone to users, ie servers on UTC, timezone +10
### Actual behavior:
* lots of issues with elasticsearch, reports, pending reminders, any function that uses a time.
### Steps to reproduce the behavior:
* install an new zammad on a server in UTC, set your desktop to +10, set up imap to fetch emails, preferable emails sent in +10 timezone, look at reports, set pending reminder, search for tickets.
I'm not 100% sure this is a bug. I have 5% of the knowledge of zammad developers, so be skeptical about this report. I might be wrong. My thinking is here:
https://community.zammad.org/t/elasticsearch-is-only-being-used-for-user-and-organisation-queries-not-ticket-queries/821/15?u=chesty
> Oh noes, I think it’s a timezone issue. I think zammad assumes server and browser are running in the same timezone? can that be? The timestamp field for created_at and updated_at, etc, are timestamp (as apposed to timestamptz) and the times in them are (for me) UTC with no timezone info, where desktops and browsers are running in +10. I guess email timestamps would be +10 too with timezone info. so 2018-06-17 10:00:00 +10, but the time that gets stored in postgres would just be 2018-06-17 10:00:00 (no +10), and the created_at would be 2018-06-17 00:00:00
>
> I think elasticsearch is timestamptz (the equivalent to) so when zammad is searching elasticsearch for a ticket within a narrow time period, the times are 10 hours out and the ticket isn’t found.
>
another project I use is odoo, it converts all times into UTC before putting them in DB, and the view is responsible for displaying the time in the right timezone, it has access to the browsers timezone setting I guess.
1 Like
system
December 3, 2019, 9:51am
5
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
