{"action":"created","issue":{"url":"https://api.github.com/repos/osTicket/osTicket/issues/3991","repository_url":"https://api.github.com/repos/osTicket/osTicket","labels_url":"https://api.github.com/repos/osTicket/osTicket/issues/3991/labels{/name}","comments_url":"https://api.github.com/repos/osTicket/osTicket/issues/3991/comments","events_url":"https://api.github.com/repos/osTicket/osTicket/issues/3991/events","html_url":"https://github.com/osTicket/osTicket/issues/3991","id":263772719,"number":3991,"title":"Ticket Lock and Timezone problems for Australia/Brisbane after daylight saving change in AEST","user":{"login":"perryk","id":806269,"avatar_url":"https://avatars1.githubusercontent.com/u/806269?v=4","gravatar_id":"","url":"https://api.github.com/users/perryk","html_url":"https://github.com/perryk","followers_url":"https://api.github.com/users/perryk/followers","following_url":"https://api.github.com/users/perryk/following{/other_user}","gists_url":"https://api.github.com/users/perryk/gists{/gist_id}","starred_url":"https://api.github.com/users/perryk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/perryk/subscriptions","organizations_url":"https://api.github.com/users/perryk/orgs","repos_url":"https://api.github.com/users/perryk/repos","events_url":"https://api.github.com/users/perryk/events{/privacy}","received_events_url":"https://api.github.com/users/perryk/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":14,"created_at":"2017-10-09T02:24:31Z","updated_at":"2018-03-10T02:08:45Z","closed_at":null,"author_association":"NONE","body":"### Prerequisites\r\n\r\n* [ Y] Can you reproduce the problem in a fresh installation of the \"develop\" branch?\r\n* [ N] Do you have any errors in the PHP error log, or javascript console?\r\n* [ Y] Did you check the [osTicket forums](http://osticket.com/forum/categories)?\r\n* [ Y] Did you [perform a cursory search](https://github.com/osTicket/osTicket/issues) to see if your bug or enhancement is already reported?\r\n\r\n### Versions\r\n\r\n![screenshot from 2017-10-08 23-59-09](https://user-images.githubusercontent.com/806269/31323141-98d7a5fe-ace6-11e7-8aa3-ad27f910b775.png)\r\n\r\n### Description\r\n\r\nAfter daylight savings started in the AEST timezone, osTicket installations set to Brisbane time are unable to reply or edit tickets as the ticket lock renew drop down windows immediately appears and if renew is selected it just waits forever. If the tick lock is returned off, the system still displays all time-dates as being 1 hour behind the actual time in Brisbane. The system report incorrect reports the database timezone as being interpreted as Australia/Melbourne.\r\n\r\nI've been around and around a few times on this, initially, I thought it started before the change to daylight saving for all the other state capitals in the AEST timezone. Brisbane is different in that it doesn't observe daylight savings whilst Melbourne and Sydney do.\r\n\r\nI found a couple of PR's which both looked to fix the lock issue, however they didn't fix the wrong time issue. In particular [this](https://github.com/osTicket/osTicket/pull/3734) PR is interesting but it only fixes cases in which there are multiple timezones which might be returned, not the case I have here, although it looks similar.\r\n\r\nIn the end, I started working with a stock standard v1.10.1 branch of the code and found there were no ticket lock problems if the system date was 30 Sept, and there _were_ problems if the system date is 1 Oct or later. This matches with the start of daylight saving AEST and confirms I don't need the other PRs. This also confirmed that the system report was always reporting the timezone being interpreted as Australia/Melbourne.\r\n\r\nFurther complicating this I worked out was that I was using a database backup from Sept for my testing and there was session data in the ost_session database which included a cached variable for the timezone.\r\n\r\nFrom what I gather there is initially a call to \"SELECT @@system_time_zone.global;\" to obtain the database timezone before the result is saved to the session data.\r\n\r\nThe select statement above returns \"AEST\" for me, however, this is then passed through the format class where the PHP function \"timezone_name_from_abbr\" is incorrectly returning \"Australia/Melbourne\" instead of \"Australia/Brisbane\" and saving this to the session data.\r\n\r\nThe timezone class has additional code for some interesting looking functions which are trying to work out ambiguities and has an array of years with daylight saving time etc, however, it looks like this code is only ever used if the database fails to report any type of timezone. The comment on the array is \"Rules compiled from jstz rules.js\". So this doesn't look to be used here.\r\n\r\nI've just worked around by always returning \"Australia/Brisbane\" always which isn't ideal but works well enough for me. \r\n\r\nThanks for any suggestions you may have on this.\r\n\r\nCheers.\r\n\r\n### Steps to Reproduce\r\n\r\n1. Change server and php timezone Australia/Brisbane. Database timezone can remain as \"SYSTEM\", changing it directly does not change the behaviour. The date should be after Oct and before Apr.\r\n2. Attempt to post a reply or internal note.\r\n\r\n**Expected behavior:** : To be able to type into the message box.\r\n\r\n**Actual behavior:** : A ticket lock is expiring soon message appears which cannot be renewed.\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/osTicket/osTicket/issues/comments/371994071","html_url":"https://github.com/osTicket/osTicket/issues/3991#issuecomment-371994071","issue_url":"https://api.github.com/repos/osTicket/osTicket/issues/3991","id":371994071,"user":{"login":"QANTau","id":1386766,"avatar_url":"https://avatars0.githubusercontent.com/u/1386766?v=4","gravatar_id":"","url":"https://api.github.com/users/QANTau","html_url":"https://github.com/QANTau","followers_url":"https://api.github.com/users/QANTau/followers","following_url":"https://api.github.com/users/QANTau/following{/other_user}","gists_url":"https://api.github.com/users/QANTau/gists{/gist_id}","starred_url":"https://api.github.com/users/QANTau/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/QANTau/subscriptions","organizations_url":"https://api.github.com/users/QANTau/orgs","repos_url":"https://api.github.com/users/QANTau/repos","events_url":"https://api.github.com/users/QANTau/events{/privacy}","received_events_url":"https://api.github.com/users/QANTau/received_events","type":"User","site_admin":false},"created_at":"2018-03-10T02:08:45Z","updated_at":"2018-03-10T02:08:45Z","author_association":"NONE","body":"Yes, MySQL and Apache have been restarted.\r\n\r\nSorry ... should have already included that info :)"}}
{"actor":{"display_login":"QANTau"}}