Reports timezone is always in GMT #17

benscanfiles · 2015-12-29T17:39:38Z

I have a potentially serious blocking bug, and that is that reports ignore the local timezone and are always in GMT. Dealing with date/time functions in php is not one of my stronger areas and I really need some help in fixing it. Even with using the server time, and client offset time, time displayed on reports AND on the main home screen are always in GMT. I have checked the cookie and have verified that it has the correct offset (-480 GMT-8). This cookie seems to get sent/set regardless of the settings you have chosen.

Personally, I would prefer to have a timezone setting in the settings page where I could simply choose what timezone I wanted to use globally. I've looked into this but frankly I'm not sure how I would do it. For the moment I need this particular bug solved before I can invest tons of time into it.

andrew867 · 2015-12-29T19:24:15Z

What is your php.ini date.timezone option currently set as?

What about the config.inc.php options $use_client_tz and $use_server_tz?

I have both config.inc.php options set to no, and my timezone is set in php.ini correctly. I don't have any issues with this. FYI php defaults to GMT when date.timezone is unset or left as default.

andrew867 · 2015-12-29T19:26:45Z

Also I'll commit an addition to config.inc.php which will allow the system to override the php.ini timezone in case you can't modify it.

andrew867 · 2015-12-29T19:31:28Z

Take a look at this commit and see if it fixes your issue 4e76ac5 if it does then fix date.timezone in your php.ini :)

benscanfiles · 2015-12-29T19:34:20Z

Sorry I just saw this. In php.ini, that was one of the first things I set:
date.timezone="America/Los_Angeles"�

I'll incorporate your changes into my fork and see if that solves my issues and report back :-)

andrew867 · 2015-12-29T19:40:47Z

While you're at it could you add an echo statement to the report your running:

echo date_default_timezone_get();

and see if the timezone matches what you've selected. Oh and what do you have selected in config.inc.php?

benscanfiles · 2015-12-29T19:50:38Z

https://drive.google.com/file/d/0B8rpAE3Gj5gZUThJNG94aWc4dkE/view?usp=sharing

At the top left I have added a line in the header echoing the timezone for the reports.

The timezone being used/picked up by the script is the same as in php.ini. Notice that the time the report was run is in PST, but all the user punches are in GMT.

andrew867 · 2015-12-29T20:08:10Z

Can you send a screenshot of the info database table?

Mine seems to be working correctly with punches stored in the database as GMT unix timestamps (I have both config.inc.php timezone options set to 'no'):

benscanfiles · 2015-12-29T20:13:52Z

Sure, can do. I set use server timezone to yes (server is in my same time zone... it's only a few miles from me), and check this out:

https://github.com/andrew867/timeclock/blob/master/functions.php#L304

Is not being set. $tzo is blank.
Check out this screenie: https://drive.google.com/file/d/0B8rpAE3Gj5gZeXJEME9VWjVfNWM/view?usp=sharing

Edit: Maybe I'm barking up the wrong tree here :-/

This is the code I'm using in header post reports:

<?php
include "header.reports.inc.php";

echo 'Timezone: ' . date_default_timezone_get();

echo "<link rel='stylesheet' type='text/css' media='screen' href='../css/default.css' />\n";
echo "<link rel='stylesheet' type='text/css' media='print' href='../css/print.css' />\n";
echo "<script language=\"javascript\" src=\"../scripts/CalendarPopup.js\"></script>\n";
echo "<script language=\"javascript\">document.write(getCalendarStyles());</script>\n";
echo "<script language=\"javascript\">var cal = new CalendarPopup('mydiv');</script>\n";
echo "<script language=\"javascript\" src=\"../scripts/pnguin.js\"></script>\n";
include '../scripts/dropdown_post_reports.php';
echo "</head>\n";

setTimeZone();
echo '<br />Use Server Timezone: ' .$use_server_tz . '
<br />Current offset is: ' . $tzo . '<br /><br />';

echo "<body onload='office_names();'>\n";
?>

benscanfiles · 2015-12-29T20:18:37Z

Here is a screenshot of the info table:
https://drive.google.com/file/d/0B8rpAE3Gj5gZVWk5d2Y5RkotV2M/view?usp=sharing

andrew867 · 2015-12-29T20:32:33Z

I remember having a lot of trouble in the past getting timezones working properly in timeclock. Here's a quick description of what happens:

If $use_server_tz is set then timeclock queries the server for the current timezone and then sets $tzo to a specific number of seconds offset (from date('Z')) that the server thinks it has from GMT.
Most functions in timeclock use something like date('Y-M-d', time() + $tzo), therefore in PHP 5.1+ when your timezone is set in php.ini, the date()/time() functions automatically compensate for the timezone difference then timeclock adds another offset back onto the previously compensated timestamp.
That is why $use_server_tz should be set to 'no' to set $tzo to 0 and allow PHP to adjust the time offset using php.ini or the date_default_timezone_set() function.
I never had a need to use $use_client_tz so it was never fixed. What should be done is a DB column added to the user and set each user's home timezone independently of the server. You could then use the date_default_timezone_set() with the returned user timezone. Relying on Javascript to set a timezone and cookie is just asking for trouble. This is good for a company who has users in different areas.
Adding onto the new DB column fix, you could also add an option to enable a 'select current timezone' dropdown on the punch in/out page that would override the user selected and server timezone. This is good for users who are on the road.

Specific to your issue PHP might be compensating automatically then something related to $use_server_tz is screwing the compensation back up. When you make some more test punches could you set the note to the current correct local time that the punch is put into the system?

benscanfiles · 2015-12-29T20:35:05Z

But when I set it to no, the same thing happens. $tzo = 0 in both cases, yes and no on use server timezone.

benscanfiles · 2015-12-29T20:43:58Z

Ok, so this is fun stuff. It's working now, but I didn't change anything except use server timezone to 0.

When I started having this trouble this morning, both client and server timezone settings were 0.

The reports are still not using the offsets except for only the new punches. Apparently instead of performing the offset at time of display, it is performing the offset before writing to the database. I don't need to point out how fail this is. This means that any time you change your timezone, you completely screwed over your timeclock.

Times should be written to the db as GMT and then the offset applied whenever written in a report or displayed.

andrew867 · 2015-12-29T20:46:48Z

I agree, it's a pretty big bug. What should happen is the punch should be stored in GMT with another column specifying what timezone it was punched from (to keep it complete with the other changes I mentioned above). Also the info table needs a unique column (probably should be renamed to punches), it's currently a PITA when using phpMyAdmin.

benscanfiles · 2015-12-29T20:49:09Z

Excellent point about the Timezone column and yes, I completely agree. I'm glad I understand what is actually going on now though. I really appreciate you time spent in helping me! :-D

andrew867 · 2015-12-29T20:52:48Z

I've opened #18, #19, and #20 outlining the issues we just found and potential fixes. Feel free to assign them to yourself if you feel like fixing them. I had originally taken over timeclock as I was developing an Arduino based NFC timeclock to use at work to track my overtime, I should dig out my old code and publish it as it seems like you might be able to make use of it!

benscanfiles · 2015-12-29T21:14:39Z

I'll see what I can do, no promises. Unfortunately it's kind of becoming clear that I won't really be able to use this for work, which puts it in the hobby column. I'll see if I can't make some improvements to it though. It has potential, just needs a few extra kicks to get it headed in the right direction.

andrew867 · 2015-12-30T03:50:20Z

Have a look at TimeTrex for your work, it's what I ended up using and seemed to work quite well.

Nexis81 · 2016-01-15T02:34:08Z

Where are you at currently with working on the time issues? Is there any insight you can provide on the issue other than what has been discussed already? I too was looking at this for work. When I noticed the time issues, I realized we couldn't use it. My company likes open source stuff so I have a time limit of 1 week to have this working or I have to move on.

benscanfiles · 2016-01-15T23:50:14Z

I finally settled on timeclockwizard.com It's extremely nice and completely web based. I didn't really like the idea behind timetrex. It looks nice, but it also looks like a pain to set up.

hjelmua · 2016-08-12T18:53:58Z

For me changing the lines in leftmain worked fine.
// $tz_stamp = mktime ($hour, $min, $sec, $month, $day, $year);
// testing better ways
$tz_stamp = time ($hour, $min, $sec, $month, $day, $year);

nextechinc · 2016-09-20T22:01:12Z

In functions.php, setTimeZone(), I added a new line 'global $tzo;'

That did the trick for me.

ddziubanski · 2016-09-20T22:36:58Z

thanks for the fix, will give it a try

On Sep 20, 2016 3:01 PM, "John" [email protected] wrote:

In functions.php, setTimeZone(), I added a new line 'global $tzo;'

That did the trick for me.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOwSwAmzqromwQHL_8eRnKdwpJkffcynks5qsFeogaJpZM4G8bh4
.

ddziubanski · 2016-10-09T19:25:35Z

Confirming, This fixed my issue

On Fri, Aug 12, 2016 at 11:53 AM, hjelmua [email protected] wrote:

For me changing the lines in leftmain worked fine.
// $tz_stamp = mktime ($hour, $min, $sec, $month, $day, $year);
// testing better ways
$tz_stamp = time ($hour, $min, $sec, $month, $day, $year);

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOwSwLFKd_Qa6FJ49Cj-Am7kmAwTDg_gks5qfMFHgaJpZM4G8bh4
.

benscanfiles mentioned this issue Dec 29, 2015

ADDED 'global' MODIFIER FOR FUNCTION REFERENCES TO GLOBAL CONFIG #15

Merged

benscanfiles mentioned this issue Dec 29, 2015

Timezone not Sync with Client TZ Setting #2

Open

andrew867 added the bug label Dec 29, 2015

andrew867 self-assigned this Dec 29, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Reports timezone is always in GMT #17

Reports timezone is always in GMT #17

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

andrew867 commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 30, 2015

Nexis81 commented Jan 15, 2016

benscanfiles commented Jan 15, 2016

hjelmua commented Aug 12, 2016

nextechinc commented Sep 20, 2016

ddziubanski commented Sep 20, 2016

ddziubanski commented Oct 9, 2016

Reports timezone is always in GMT #17

Reports timezone is always in GMT #17

Comments

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

andrew867 commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 29, 2015

benscanfiles commented Dec 29, 2015

andrew867 commented Dec 30, 2015

Nexis81 commented Jan 15, 2016

benscanfiles commented Jan 15, 2016

hjelmua commented Aug 12, 2016

nextechinc commented Sep 20, 2016

ddziubanski commented Sep 20, 2016

ddziubanski commented Oct 9, 2016