Osticket: 1.10 Timezone issue / Time ahead of actual time (PHP 5.6.x, PHP 5.5.x related issue)

[Chefkeks]

Hi @greezybacon and @protich

not sure if either you noticed the following comments from the stabilize 1.10 PR so I thought would be best to open this separate issue report. It seems like time(zone) settings are broken/wrong with PHP 5.6.x. (using intl extension - have not tried without intl extension yet). Just look at the comments/links below:

Issue (screenshot shows 1.10-RC1, but still in 1.10-RC2)
https://github.com/osTicket/osTicket-1.8/pull/2056#issuecomment-124461437

Seems like it's related to PHP as @mfelber found out:
https://github.com/osTicket/osTicket-1.8/pull/2056#issuecomment-124475586

Michael

[greezybacon]

I'll try and reproduce it. I was really hoping it was fixed by 4377356b49811936e54ad8f50588b91346d58862

[ghost]

@greezybacon Why should https://github.com/osTicket/osTicket-1.8/commit/4377356b49811936e54ad8f50588b91346d58862 fix a problem on a linux system? It sounds like it is for windows.

I only have seen this problem with php 5.6.x. Maybe php 5.6.x has a bug or a changed behavior so the actual code doesn't work like expected with prior php versions. Here is a screenshot that is showing the difference depending on the used php version (with a bitnami ubuntu lamp stack):

I think the time formatting example should show the same time even with different php versions, but it does not. With php 5.6.x the time is one hour ahead (compared to php 5.4.x or php 5.5.x) like in this view.

[ntozier]

The time on that page has never been 'right'. It's an example to show you the formating, not the actual time.

[Chefkeks]

@ntozier
That's correct - it has never been right, but as you can see with PHP 5.6.11 it's 12:15PM and with PHP 5.4.40 it's 11:15PM - so 1 hour difference. For some reason PHP 5.6.x seems to behave different.

On our server (with PHP 5.6.x and intl php extension) osTicket 1.9. behaves "normal" -- time of tickets is correct. Any DPR / RC of 1.10 behaves weird - it is showing that a ticket is going to be created "in about an hour" or so since the time is 1 hours ahead for some reason.

Since 1.9 and 1.10 run here on the same server and older PHP versions behave normal, the must have been some change in PHP 5.6.x that causes this behavior. I mean it's a bit strange when you actually expect the system to show that you just opened a ticket or posted a response and what the system is actually telling you is that you posted a ticket "in about xx (hours|minutes)" which is really confusing.

So it's about the wrong time caused by some PHP 5.6.x changes and not the preview in osTicket. See also the first link from the opening: https://github.com/osTicket/osTicket-1.8/pull/2056#issuecomment-124461437

Hope I could explain well enough that you understand what I meant ;)

[ghost]

@ntozier I'm aware that this time preview not reflects the current time.

But my thoughts as I posted this screenshots were that this could be a helpful hint for the origin of this unexpected behavior with 1.10 and php 5.6.

Both servers were configured identical and both os time was 13:15.
Normally the preview shows then 11:15, but with php 5.6 the time was one hour in front like it is described in #2056.

In this preview the timezone settings and the offset seems not be considered.
So my idea was when the time is different in this preview the origin of this different behavior is maybe not in the timezone and offset code but maybe in some other place (like time formatting) before the timezone and offset code is applied.

I don't really know if this make sense because unfortunately my coding knowledge is too bad...

[ghost]

I just want to add that this also occurs with php versions before 5.6 (for example 5.5.11) like it is described in the mentioned comment https://github.com/osTicket/osTicket-1.8/pull/2056#issuecomment-124475586 (sorry I didn't remember).

Maybe @Chefkeks should adjust the title therefore ;-).

So something must have changed already with php 5.5.x

I have noticed this for example:
http://evertpot.com/php-5-5-10-timezone-changes/

[ARiber]

Yes, I actually have the same issue. I am using PHP Version 5.5.27-1~dotdeb+7.1

So it is definitely already with Version 5.5.x

[ARiber]

When I inspect the time I notice the following
My Server is set to: Europe/Berlin
The server is also located in: Europe/Berlin
PHP.ini is set to: Europe/Berlin
OSTicket System is set to: Europe/Berlin
Profile Timezone is set to: Asia/HongKong

Inside the ticket, inspecting the time it says

time class="relative" title="Montag, 31. August 2015 08:44" datetime="2015/-8/31T02:44:47+02:00" in 51 minutes

But actually when the post was created it was 9:44 and in Germany it was 3:44... but it shows 02:44:47...

[greezybacon]

I've gotten to the root of this. Timezones like CDT (Central Daylight Time) are valid starting in PHP 5.5, however; these zones have static offsets. (-6 for CDT). Therefore, they cannot be used when comparing offsets to dates which should be in CST (standard time), and hence the one hour offset (which will be magically corrected in November).

[greezybacon]

Can anyone check with the patch in #2570?

[Chefkeks]

@greezybacon
Have not tested the patch yet, but I think that the following comment is maybe helpful too:
http://php.net/manual/de/function.time.php#117251

Since I ran into this issue myself with one of our internal PHP projects (upgraded to PHP 5.6.x) and searched the web hours for information about that issue (and a fix) I really hope that comment above will help :)

[ARiber]

@greezybacon
Just tested your patch, sorry it doesn't seem to work.
Server location is in Germany.
PHP Version 5.5.27-1~dotdeb+7.1

[ghost]

@greezybacon The patch works like a charm :-) I have tested it with php 5.5.27 and 5.6.12.

@ARiber Did you logout after appending the patch? In my case I had to logout and login again to see the corrected behavior..

[ARiber]

@mfelber
yes, you are correct. You have to log out and back in in order to make it work

Thanks @greezybacon

[febrile42]

Patch resolved this issue for me as well. PHP 5.6.2-1

Thanks @greezybacon !

[greezybacon]

Hey everyone, I've changed the patch to provide significantly better performance on such databases that report abbreviated time zones. Could anyone verify again with the (updated) patch in #2570?

[ARiber]

Hi,
yes, i can confirm that it works by me. I also logged out / in and checked different scenarios. Could not find any problem...

[ghost]

Updated Patch #2570 works. No problems occured.

[balojs]

not works on PHP 5.4.16 :( @greezybacon CST?
http://stackoverflow.com/questions/15870778/php-datetime-instance-using-timestamp-returning-wrong-results

[robintoy]

Does not work for me, instead it stops displaying the ticket list when it hits the loops call to the time.

In the way of logs I do not get any DB errors but I do get the following error on my web server: -

[Sat Jun 18 14:49:58.297826 2016] [fcgid:warn] [pid 21686] [client 81.168.21.81:46779] mod_fcgid: stderr: PHP Parse error: syntax error, unexpected 'if' (T_IF) in /home/hp3-linc1-nfs2-y/538/531538/user/htdocs/include/class.timezone.php on line 170, referer: http://helpdesk.strobe-it.co.uk/scp/

Line 170 is

if (!in_array($TZ, array('UTC', 'GMT')) && strpos($TZ, '/') === false)

Just in case I have missed any lines or done a typo I downloaded the full file which now didn't kill my display or cause the server to error; but didn't solve the issue either

[greezybacon]

@robintoy didn't you also say that you are logged out when posting a reply? Could you post your config from the system information page and from your system and profile date/time config?

[robintoy]

Hi @greezybacon

details are: -
(PS logged out on 1.10-rc3, we now back on rc2)

[greezybacon]

@robintoy I was hoping to also see the database information below this part

[robintoy]

No probs...

[robintoy]

Just in case it helps @greezybacon

Server Details are: -
OS: Linux Operating (Not sure which as a Clustered Hosting Platform from Fasthosts UK)
Web Server: Apache
PHP: 5.6.20
MySQL: 5.0.95

[robintoy]

Might sound odd but is the time pulled from the DB or from the webserver?

I ask as UTC and GMT are not exactly the same in countries like the UK due to our lovely "British Summer Time" BST.
http://www.timeanddate.com/time/gmt-utc-time.html

[greezybacon]

The database is reporting "GMT", which, according to PHP is the same as "UTC"; however, I wonder if the database (MySQL) does not.

php > var_dump(timezone_name_from_abbr('GMT'));
string(3) "UTC"

[greezybacon]

@robintoy why not use a different timezone which avoids the ambiguity, e.g. Europe/London?

[robintoy]

@greezybacon on the webserver or MySQL?
I know for sure I cannot alter webserver as it a shared platform which I only have FTP access to.

just been looking to see if there would be compatibility issues between the two systems (PHP and MySQL) with different time zones and what a can of worms.

One very good article is
http://stackoverflow.com/questions/19023978/should-mysql-have-its-timezone-set-to-utc

[robintoy]

Just looking at the MySQL DB I cannot change that time zone either as I just have access to my table and nothing else.

This the problem when you using hosting companies I guess.

[greezybacon]

I'm thinking that version of MySQL is somewhat outdated, and recent versions of PHP do not have a "GMT" timezone. It seems PHP assumes that GMT == UTC, which I think is not the case here. I'm wondering if, at least for newer versions of PHP and older versions of MySQL (maybe all of them), we should assume GMT from MySQL means Europe/London in PHP

[greezybacon]

$ php -a
php > var_dump(timezone_identifiers_list());
array(420) {
  [0] =>
  string(14) "Africa/Abidjan"
  [1] =>
  string(12) "Africa/Accra"
...

"GMT" is not included in the list for PHP 5.6.21

[robintoy]

That would make sense as we never used to have this issue and the database server has not changed.

I do have a different DB server available as I have moved the website to the new cluster platform, but not 100% on doing this yet as the cluster system so far stinks and is down more than up.

Hopefully that DB is more up to date but your idea makes sense as we all seem to have just a 1 hour issue.

[greezybacon]

However, considering that it works properly on your setup in v1.10-rc.2, it seems there should be some regression between the two releases

[robintoy]

Time has not worked since we jumped from v1.9.9 (I think it was then) to v1.10-rc2.

But the logout bug is new in v1.10-rc3, and not related to time I believe if that what's you mean.

[greezybacon]

@robintoy thanks. That clarification helps

[robintoy]

Thanks, was worried then as getting late and thought I was speaking crap myself. I might not be the beat coder in the world but good tester and methodical problem solver.

[greezybacon]

@robintoy could you try the patch in #3219 to see if it addresses the timezone issue?

[robintoy]

Tested and works perfectly!!!
Screenshot added to #3219

[rejivincentc]

OS v1.10 Timezone issue...

Please assist

About this osTicket Installation
Server Information
osTicket Version v1.10 (901e5ea) — Up to date
Web Server Software Apache/2.2.27 (Unix) mod_ssl/2.2.27 OpenSSL/1.0.1e-fips
MySQL Version 5.1.73
PHP Version 5.4.45
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
APCu Improves overall performance
Zend Opcache Improves overall performance
PHP Settings
cgi.fix_pathinfo "1" is recommended if AJAX is not working
date.timezone Africa/Johannesburg
Database Information and Usage
Schema bwcelsup_supportostkt (localhost)
Schema Signature 98ad7d550c26ac44340350912296e673
Space Used 0.29 MiB
Space for Attachments 0.01 MiB
Timezone CAT (Interpreted as America/Anchorage)

Installed Language Packs
English - US (English) —
en_US — include/i18n/en_US

[ntozier]

So @rejivincentc you might want to actually tell us what the problem is that you are experiencing. The screen shots are great and all but with out you telling us what you see as the problem, its sort of like showing us a picture of a car, and telling us to fix it.

[rejivincentc]

Hi @ntozier , Our timezone is Africa/Johannesburg, We changed timezone setting in Date and Time Options,Preferences but at the time of ticket creation or posting its displaying wrong time...

Suppose, if we created the ticket at 01:05PM (actual time) but its system showing 12:04AM

[ntozier]

And did you also change your accounts timezone?

[rejivincentc]

@ntozier Yes

[elambro]

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;
    }