Osticket: ticket time is showing wrong

Created on 4 Feb 2017  ·  28Comments  ·  Source: osTicket/osTicket

Ticket time is showing wrong . I have checked in my server time and my sql server time is correct there.

os info
os ticket my sql time
os ticket
os timezone
osdate

Ticket time is showing wrong . I have checked in my server time and my sql server time is correct there.

regression bug

Most helpful comment

To remove timezone issue with osticket DB timezone as : IST (Interpreted as Asia/Jerusalem)
http://osticket.com/forum/discussion/89257/v1-10-timezone-misinterpreted
https://github.com/osTicket/osTicket/issues/3654
https://github.com/osTicket/osTicket/issues/3583

we have done quick fix ain include/class.config.php

Search for line having
function getDbTimezone()

in this function you would last line as
return $this->get('db_timezone');
Comment this line , and add below two line
$dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone;

The function would like below.
function getDbTimezone() { if (!$this->exists('db_timezone')) { require_once INCLUDE_DIR . 'class.timezone.php'; $this->persist('db_timezone', DbTimezone::determine()); } $dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone; // return $this->get('db_timezone'); }

This will help a lot till proper code fix is there.

All 28 comments

Try to check your php.ini conf and set your time zone..

time zone in my php.ini is correct

Thanks&Regards
Lijo Joseph George
Technical Team|| ManoramaOnline
Mobile: +91 9895336448 | Office : +91 0481 2563646 | Ext :670
Visit us:www.manoramaonline.com | LinkedIn | Facebook | Twitter

From: iHunt NSA notifications@github.com
To: osTicket/osTicket osTicket@noreply.github.com
Cc: lijo joseph george lijojosephgeorge@mm.co.in, Author
author@noreply.github.com
Date: 06-02-2017 AM 09:19
Subject: Re: [osTicket/osTicket] ticket time is showing wrong
(#3654)

Try to check your php.ini conf and set your time zone..

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

***********Malayala Manorama***********
The contents of this E-mail (including the contents of the enclosure(s) or attachment(s) if any) are privileged and confidential material of Malayala Manorama (MM) and should not be disclosed to, used by or copied in any manner by anyone other than the intended addressee(s). In case you are not the desired addressee, you should delete this message and/or re-direct it to the sender. The views expressed in this E-mail message (including the enclosure(s) or attachment(s) if any) are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Malayala Manorama.
This e-mail message including attachment/(s), if any, believed to be free of any virus. However, it is the responsibility of the recipient to ensure that it is virus free and MM is not responsible for any loss or damage arising in any way from its use.


If the time is wrong as you state, what should the time be? By how much is it off?

Seem that its showing time of Timezone IST (Interpreted as
Asia/Jerusalem) not of Asia/Kolkata I need the time of Asia/Kolkata for
the tickets.

Thanks&Regards
Lijo Joseph George
Technical Team|| ManoramaOnline
Mobile: +91 9895336448 | Office : +91 0481 2563646 | Ext :670
Visit us:www.manoramaonline.com | LinkedIn | Facebook | Twitter

From: Fabian Dellwing notifications@github.com
To: osTicket/osTicket osTicket@noreply.github.com
Cc: lijo joseph george lijojosephgeorge@mm.co.in, Author
author@noreply.github.com
Date: 06-02-2017 PM 02:41
Subject: Re: [osTicket/osTicket] ticket time is showing wrong
(#3654)

If the time is wrong as you state, what should the time be? By how much is
it off?

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

***********Malayala Manorama***********
The contents of this E-mail (including the contents of the enclosure(s) or attachment(s) if any) are privileged and confidential material of Malayala Manorama (MM) and should not be disclosed to, used by or copied in any manner by anyone other than the intended addressee(s). In case you are not the desired addressee, you should delete this message and/or re-direct it to the sender. The views expressed in this E-mail message (including the enclosure(s) or attachment(s) if any) are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Malayala Manorama.
This e-mail message including attachment/(s), if any, believed to be free of any virus. However, it is the responsibility of the recipient to ensure that it is virus free and MM is not responsible for any loss or damage arising in any way from its use.


Well, this is already know: #3583

Looked into it and are completely confused...

So in the ost_config is correct 'Asia/Kolkata' (+5:30), in class.format.php function datetime $cfg->getTimezone() is 'Asia/Kolkata' (+5:30) but 2 seconds later after passing it to IntlDateFormatter we are in 'Asia/Jerusalem' (+4:30). How??

Edit: Found it. It's an error in the IntlDateFormatter.

<?php
$formatter = new IntlDateFormatter('de',3,3,'Asia/Kolkata',IntlDateFormatter::GREGORIAN,null);
    echo $formatter->format(time());
?>

This should be 'now + 5:30' but is 'now + 4:30'!

@fdellwing We've ran into this issue on multiple occasions do you have any more details to put in a fix?

Not yet, have to take a closer look at the IntlDateFormatter, if there are any workarounds.

From #3583

dbinoj commented on Dec 31, 2016
The timezone returned by timezone_name_from_abbr can not be trusted as it just selects the first result sorting the tz name alphabetically. This messes up times displayed in the site even though timezone in OSTicket System Settings, OSTicket User Prefs, php.ini, MySQL, Server OS are all set to the same value.

Eg. IST refers to Israel/Indian/Irish Standard Times (Ref: List_of_time_zone_abbreviations)
One may intend to use Indian/Irish timezone but "Asia/Jerusalem" comes first alphabetically.
Few other TZs which I found to have duplicates are ACT, AMT, BST, etc.,

Either function get_from_database in class.timezone.php:165 should be modified to translate ambiguous timezones with some other reference value or a better method must be implemented.

Related StackOverflow answer: http://stackoverflow.com/a/30958892

It seems like the interpretation can change for strange reasons. CST db_timezone was being interpreted as UTC in a test install... I restarted the server twice and had the same issue. To debug it I started installing php-devel, php-xdebug and restarting the webserver... but then the problem disappeared and CST correctly resolved to America/Chicago. 0_0

CST will never be interpreted as UTC by timezone_name_from_abbr. You must have run in another problem. Did you manually queried your DB for @@system_time_zone? The old version (without my PR) just queries the DB for this.

To remove timezone issue with osticket DB timezone as : IST (Interpreted as Asia/Jerusalem)
http://osticket.com/forum/discussion/89257/v1-10-timezone-misinterpreted
https://github.com/osTicket/osTicket/issues/3654
https://github.com/osTicket/osTicket/issues/3583

we have done quick fix ain include/class.config.php

Search for line having
function getDbTimezone()

in this function you would last line as
return $this->get('db_timezone');
Comment this line , and add below two line
$dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone;

The function would like below.
function getDbTimezone() { if (!$this->exists('db_timezone')) { require_once INCLUDE_DIR . 'class.timezone.php'; $this->persist('db_timezone', DbTimezone::determine()); } $dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone; // return $this->get('db_timezone'); }

This will help a lot till proper code fix is there.

Thanks all,
It has been fixed

@deependhulla I hope you don't want to promote that as a valid solution. If you want a proper solution, take a look at my PR #3663

@fdellwing my suggestion is for quick fix, so that work get started specially who are looking forward to implement osticket and have got all correct but basic timezone feature is creating problem to start off , this would help them using and exploring octicket's features and power.

Actually would prefer original core osticket fix this timezone issue asap.
and/or give option for also selecting time-zone for database too.

overall I love osticket.
thanks to octicket team too for such a wonderful product.

For Googlers, if your database time is set to GMT, OSTicket reads this as 'Europe/London' instead of UTC. Your times will then be 1 hour off during DST. To fix this, change includes/class.config.php. Change the method OsticketConfig::getDbTimezone to this:

function getDbTimezone() {
        if (!$this->exists('db_timezone')) {
            require_once INCLUDE_DIR . 'class.timezone.php';
            $this->persist('db_timezone', DbTimezone::determine());
        }
        $db = $this->get('db_timezone');
        if ( $db === 'Europe/London') {
            $db = 'UTC';
        }
        return $db;
    }

@deependhulla ...Thank you very much....your given a proper solution..!!!

耐你们

Yes, this patch good, but this is hardcoded function. Im using Asia/Yekaterinburg (GMT +5.00) but in osticket i see in tickets date as GMT +4.00.
@deependhulla thank you

To remove timezone issue with osticket DB timezone as : IST (Interpreted as Asia/Jerusalem)
http://osticket.com/forum/discussion/89257/v1-10-timezone-misinterpreted

3654

3583

we have done quick fix ain include/class.config.php

Search for line having
function getDbTimezone()

in this function you would last line as
return $this->get('db_timezone');
Comment this line , and add below two line
$dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone;

The function would like below.
function getDbTimezone() { if (!$this->exists('db_timezone')) { require_once INCLUDE_DIR . 'class.timezone.php'; $this->persist('db_timezone', DbTimezone::determine()); } $dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone; // return $this->get('db_timezone'); }

This will help a lot till proper code fix is there.

Hi
We were facing the same issue and had applied the above patch in 1.10.5. This has been working well.

However we recently upgraded to 1.12.2 and all our ticket times were weird again, this time it was advancing by 2 hours 30 mins (as if the timezone is +8 instead of +5.30). We just applied the same patch and seems to be working well.

Is the bug still getting carried from 1.10. to 1.12?

To remove timezone issue with osticket DB timezone as : IST (Interpreted as Asia/Jerusalem)
http://osticket.com/forum/discussion/89257/v1-10-timezone-misinterpreted

3654

3583

we have done quick fix ain include/class.config.php
Search for line having
function getDbTimezone()
in this function you would last line as
return $this->get('db_timezone');
Comment this line , and add below two line
$dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone;
The function would like below.
function getDbTimezone() { if (!$this->exists('db_timezone')) { require_once INCLUDE_DIR . 'class.timezone.php'; $this->persist('db_timezone', DbTimezone::determine()); } $dvd_db_timezone='Asia/Kolkata'; return $dvd_db_timezone; // return $this->get('db_timezone'); }
This will help a lot till proper code fix is there.

Hi
We were facing the same issue and had applied the above patch in 1.10.5. This has been working well.

However we recently upgraded to 1.12.2 and all our ticket times were weird again, this time it was advancing by 2 hours 30 mins (as if the timezone is +8 instead of +5.30). We just applied the same patch and seems to be working well.

Is the bug still getting carried from 1.10. to 1.12?

not aware of 1.12 .. but this fix worked for us on osTicket (v1.14.2) again.

I tried both solutions and I might be wrong but I think none worked for me. Also I just updated to 1.14.2 but I dont think there was a fix for this on this version.

Before this fix I saw MST (Interpreted as America/Denver) with 1 hour less than my time.

After doing the solution user @deependhulla proposed above I at least can see my real timezone selected in the Timezone section which is America / Mexico_City but now my time is off by 2 hrs.

Even if I try other time zones more advanced in time for example "America/New_York" which is 2 hours ahead and could compensate my 2 hrs it ends up 4 hrs before not ahead.

Also I checked my server time and it is in MST with the correct time. I checked this by doing the command "date" on the terminal.

Anyone still having this problem? I understend the problem is closed but I cant fix it.

@perezalvarezhi

What is your System Timezone set to (Admin Panel > Settings > System > Date and Time Options > Default Timezone)? Is it America / Mexico_City?

Also, what is your Profile Timezone set to (Profile > Preferences > Localization > Timezone)?

Cheers.

@perezalvarezhi

What is your System Timezone set to (Admin Panel > Settings > System > Date and Time Options > Default Timezone)? Is it America / Mexico_City?

Also, what is your Profile Timezone set to (Profile > Preferences > Localization > Timezone)?

Cheers.

Hey there @JediKev I think while reading your questions you helped me figure it out.
I had to enter the default time zone as the same as my server which is in Pacific (Before I stated it is on MST but it is not, it is on Pacific) and then my agent profile in the time zone it is located.

I selected in Admin Panel > Settings > System > Date and Time Options > Default Timezone "America/Los_Angeles" and then in my profiles I had America/Mexico_City.

This way it worked fine.

Thanks!

@perezalvarezhi

Awesome! I'm glad you got this resolved!

Cheers.

Hi all !
I know this is 2020, but this issue still remains... Had to edit the file class.config.php and return my timezone for this to work... Thank you
EDIT: Sorry, Latest threads are already 2020 . I'm using the latest version 1.14.3

@JediKev another one with this bug

@antiuser

Cool.. you never responded to my message in your issue thread. #5522

Cheers.

@JediKev this bug found on 1.12.2 version, and i told about this in issue information (up to 1.12.6), this issue comes from old time, and no reaction. Im assume that ticket should be reopened

Was this page helpful?
0 / 5 - 0 ratings