Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reports timezone is always in GMT #17

Open
benscanfiles opened this issue Dec 29, 2015 · 23 comments
Open

Reports timezone is always in GMT #17

benscanfiles opened this issue Dec 29, 2015 · 23 comments
Assignees
Labels

Comments

@benscanfiles
Copy link
Collaborator

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Collaborator Author

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
Copy link
Owner

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
Copy link
Collaborator Author

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
Copy link
Owner

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'):

image
image
image

@andrew867 andrew867 added the bug label Dec 29, 2015
@andrew867 andrew867 self-assigned this Dec 29, 2015
@benscanfiles
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@andrew867
Copy link
Owner

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
Copy link
Collaborator Author

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

@benscanfiles
Copy link
Collaborator Author

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
Copy link
Owner

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
Copy link
Collaborator Author

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
Copy link
Owner

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
Copy link
Collaborator Author

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
Copy link
Owner

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

@Nexis81
Copy link
Contributor

Nexis81 commented Jan 15, 2016

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
Copy link
Collaborator Author

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
Copy link

hjelmua commented Aug 12, 2016

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
Copy link

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

That did the trick for me.

@ddziubanski
Copy link

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
Copy link

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
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants