Having the issue where an an agent (located in the midwest - America/Chicago timezone) cannot edit a ticket because the system says their lock is expiring soon / has expired (This appears as soon as they open the ticket and start editing). Server (and database) are set to America/Phoenix timezone.

Server OS is Rocky 8

Here is the copy/paste from dashboard-> information
osTicket Version v1.16.1 (b42ddc7) — v1.16.2 is available
Web Server Software Apache
MySQL Version 10.3.28
PHP Version 8.0.18
PHP Extensions
gdlib Used for image manipulation and PDF printing
imap Used for email fetching
xml XML API
xml-dom Used for HTML email processing
json Improves performance creating and processing JSON
mbstring Highly recommended for non western european language content
phar Highly recommended for plugins and language packs
intl Highly recommended for non western european language content
fileinfo Used to detect file types for uploads
zip Used for ticket and task exporting
APCu Improves overall performance
Zend Opcache Improves overall performance
PHP Settings
cgi.fix_pathinfo "1" is recommended if AJAX is not working
date.timezone America/Phoenix
Database Information and Usage
Schema XXXXXXX (localhost)
Schema Signature c37e165651dc289240fee7d244990ac1
Space Used 4.66 MiB
Space for Attachments 1.52 MiB
Timezone MST (Interpreted as America/Denver)

Here is the output of running SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;

Seems to me like it's an issue with the agent browser javascript not converting from server/db time to local time correctly.

    gregpost

    Have them try changing and resetting their timezone in their agent profile and see if that helps. Also have them try clearing their session/cache/cookies and retrying.

    Cheers.

        24 days later

        KevinTheJedi

        Thanks Kevin. I have tried resetting everything, and just upgraded to the latest codebase (16.3 via github) I noticed that there was a time related issue in the release notes for 16.2.

        Tried using private browsing / reseting profile tz, clearing cache history... So I think I checked all the boxes... still having the same issue.

        Any chance this is a bug due to America/Phoenix (server location / tz) being a outlier when it comes to US time zones? (Most) of Arizona does not observe daylight savings. Vs Chicago TZ (My location) which does? This means that the time differential is 1 hour in winter and 2 hours during savings time...

            Unfortunately I am not able to change the TZ of the server. It's running within the University's VM environment.

              Write a Reply...