Reports timezone is always in GMT

benscanfiles commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

benscanfiles commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

andrew867 commented 8 years ago

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 commented 8 years ago

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

benscanfiles commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

Nexis81 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

That did the trick for me.

ddziubanski commented 8 years ago

thanks for the fix, will give it a try

On Sep 20, 2016 3:01 PM, "John" notifications@github.com 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 https://github.com/andrew867/timeclock/issues/17#issuecomment-248448236, or mute the thread https://github.com/notifications/unsubscribe-auth/AOwSwAmzqromwQHL_8eRnKdwpJkffcynks5qsFeogaJpZM4G8bh4 .

ddziubanski commented 8 years ago

Confirming, This fixed my issue

On Fri, Aug 12, 2016 at 11:53 AM, hjelmua notifications@github.com 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 https://github.com/andrew867/timeclock/issues/17#issuecomment-239530524, or mute the thread https://github.com/notifications/unsubscribe-auth/AOwSwLFKd_Qa6FJ49Cj-Am7kmAwTDg_gks5qfMFHgaJpZM4G8bh4 .

andrew867 / timeclock

Reports timezone is always in GMT #17