| Project: | ProjectPier |
| Version: | 0.8.6-stable |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | miknight |
| Status: | new |
Description
On the dashboard, in the list of recent events, tasks and messages are displayed with the date or with "Today" or "Yesterday" with a corresponding background color (depending on the theme).
The problem is that the code that decides to put "Today" and "Yesterday" seems to compare the time to GMT or something like that instead of the local timezone. See attachment to see what shows up: 2 actions on 2 different days that show up as "Today".
| Attachment | Size |
|---|---|
| Dashboard.jpg | 64.29 KB |
I'm having trouble reproducing this Tim. Would you be able to send me either steps to reproduce it or a dump of your pp_application_logs table?
I too am seeing this error, exactly as reported by Tim. Won't include pic but will include bit of application_logs table as requested by miknight.
It's 23:20:00 on Feb 6 right now and all the entries below(even those *really* entered today) display as 'Yesterday' on the Dashboard.
Please forgive me for not attaching a file -- I can provide further detail as requested later.
---------
| 90 | 1 | 3 | 57 | Examine Everyone.net service utility -- terminate ... | ProjectTasks | 2008-02-06 04:58:43 | 1 | add | 0 | 0 |
| 91 | 1 | 3 | 58 | Determine number of users | ProjectTasks | 2008-02-06 05:31:39 | 1 | add | 0 | 0 |
| 92 | 1 | 3 | 35 | Research and contrast reliable outsource solutions... | ProjectTasks | 2008-02-06 05:31:56 | 1 | edit | 0 | 0 |
| 93 | 1 | 3 | 7 | Symantec Anti-spam Security Subscription Expires | ProjectMilestones | 2008-02-06 22:58:46 | 1 | add | 0 | 0 |
| 94 | 1 | 3 | 15 | Mail server replacement | ProjectTaskLists | 2008-02-06 22:59:45 | 1 | edit | 0 | 0 |
| 95 | 1 | 3 | 58 | Determine number of users | ProjectTasks | 2008-02-06 23:01:12 | 1 | edit | 0 | 0 |
| 96 | 1 | 3 | 59 | Obtain configuration access info for DSL modem/rou... | ProjectTasks | 2008-02-06 23:04:19 | 1 | add | 0 | 0 |
| 97 | 1 | 3 | 60 | Review all Registration and DNS configuration | ProjectTasks | 2008-02-06 23:09:50 | 1 | add | 0 | 0 |
| 98 | 1 | 3 | 61 | Review DSL router configuration options(security, ... | ProjectTasks | 2008-02-06 23:11:18 | 1 | add | 0 | 0 |
------------------------------------------------
I haven't even looked at the code yet so perhaps Tim's suggestion around GMT comparison is apt. I will say that tasks 90-92 were actually entered on 2008-02-05 localtime and in the evening. DB times/dates are stored as GMT?
I'll try to be more helpful when I get a bit more time.
Thanks senor_jt. I can confirm the dates are stored in GMT. Hopefully with your sample data I/someone can figure it out. Any more data is welcome if anyone else has an example too!
Actually, it also happens in the milestone page: right now, I have a milestone set for tomorrow that appears in red as "Today".
I was thinking about the problem and it seemed to me there was something to be talked about for the cases when different people on different timezones work on the same project but I can't remember what the problem could have been... Hum... I'll have to think about it again.
Just a couple of notes to follow-up my data submission...
Both my company and the client assigned to the project are in the PST timezone(Los Angeles, CA USA).
Outside of today/yesterday entries, all seems to display correctly. I.e., data entries shown above correctly show up as Feb 5 and Feb 6 entries now.
Still being completely ignorant of the code, that would lead me to think that the error was localized to the logic around "Today" and "Yesterday" only(and not an error with possibly general GMT to local timezone routine).
Hope to get a chance to learn a bit and check into it soon.
OK guys, I think I have come up with a solution. Originally it was doing a comparison between the current date in GMT and the event date, also in GMT. Sometimes these would be on the same day in terms of GMT, but not on the same day for people in other timezones.
My patch pushes both comparison dates into the user's timezone, so it should accurately display whether it the event happened 'today' or 'yesterday'.
Thanks very much for the sample data senor_jt!
Miknight, your patch works except for when the timezone is in fact GMT.
I modified the function DateTimeValue::advance() to do something even if the timeshift is null.
For some reasons, the patch looks as if it was rewriting the whole ApplicationLog.class.php. Probably because of a different base revision...
Nevermind the previous one. Eclipse, once again, tricked into believing that I was formatting the files properly...
Anyway, this one should be better.
Just applied 3...will update . So far seems to have "fixed" our issue.
Our server is on PST and out users are on PST time...before the patch we where off by about 6 hrs!
The milestones still show the problem unfortunately.
We should probably add a function User::compareToUserTimeZone or something like that because I started to copy and paste miknight's code snippet a few times...
We've also noticed some discrepancies when dates are being displayed.
Wanted to join this thread to keep up.
Tried a few things to diagnose:
Changed the milestone 'due_date' to '2008-02-25 12:00:00' and refreshed the page and noticed everything was kosher. Note the noon time.
Changed my user's timezone to GMT and also noticed things were ok as well as the parent company timezone to GMT and again, things were fine.
One thing I still noticed was that 'updated_on' continues to show 5 hours ahead:
2008-02-15 18:46:10
where the time on my local machine (working on a local version for dev) was in fact:
2008-02-15 13:46:10
at the time I edited the milestone.
I haven't yet gotten the patch but will have a gander and probably do it on my dev version to see what the effects are.
Thanks.
/s
I think this is the same problem I'm having, but I'm not sure how to apply the patch. Could someone point me to some instructions on tips to install the patch.
Thanks
To Let everyone know, the
app_log_today_yesterday_fix_3.patch
file submitted by Tim has a local path problem
It was pointing to:
--- C:/Documents and Settings/tboucher/My Documents/programming/PHP/PP_today_yesterday_bug/environment/classes/datetimevalue/DateTimeValue.class.php (revision 114)
+++ C:/Documents and Settings/tboucher/My Documents/programming/PHP/PP_today_yesterday_bug/environment/classes/datetimevalue/DateTimeValue.class.php (working copy)
I have attached a new version with no other changes other than fixing the paths
arkitekt,
Instructions on installing patches are here:
http://projectpier.org/patch/apply
I applied the most recent patch but Milestones that are due tomorrow continue to display as due Today.
I edited the milestone to ensure it is due tomorrow 7/30, it shows in the recent activities as updated Today, 7/29 but displays as Due Today in the "Late milestones / Today milestones" dashboard view and Today Milestones in the Milestones view. My server is 6 hours ahead of me, it seems milestones are still using the server time to figure if the Milestone is due rather than the user configured timezone.
Thanks!
Alane
I had the same problem after installing a few days ago. I was able to fix my problem by adjusting the time zone in the environment/environment.php file to the correct time zone.
My time zone is PST so I simply added -7 (accounting for daylight savings time) after GMT.
// Configure PHPini_set('short_open_tag', 'on');
ini_set('date.timezone', 'GMT-7');
if (function_exists('date_default_timezone_set')) {
date_default_timezone_set('GMT-7');
} else {
putenv('TZ=GMT-7');
} // if
PP didn't notice anything as far as messages and such are considered so everything is looking good now (My users and I (and the server) are all in the PST zone so I left our company and user accounts at GMT-7 in the admin panel).
Hope this helps someone.
And since this is my first post on the forum let me just say I'm excited for the future of this project. Keep up the good work!
This fixed every incident (so far that I can tell) except for when I'm at my dashboard... It STILL says that due "Today" when in fact it's due tomorrow.
Driving me batty!
Was having the exact same issue, mfive.
I applied the patch which resolved the time issues with my 'recent activities' list.
Then I manually changed the GMT in environment/environment.php from 'GMT' to 'GMT-7' which is my time zone (during daylight savings time anyhow) as mrjohnnycake suggested above you which fixed the problem where things due 'today' were showing up as a day late.
However, after all of that it was still showing the wrong due date (one day early) in the project overview, even though it showed the correct number of days late and the correct due date in the milestones page.
I resolved that by changing format_descriptive_date($late_milestone->getDueDate()) to format_descriptive_date($late_milestone->getDueDate()->getTimestamp() + 86400) on lines 41 and 43 of views/project/overview.php to FORCE it to add an extra day to wherever it was getting the erroneous due date. If anyone could find the source of that value, it would be awesome... I gave up after 45 minutes of digging.
Not an ideal solution (nor is manually changing GMT in environment.php) but it fixed the problem for now.
What a mess! This really needs to be cleaned up in the next release or sooner with a patch (from someone who is better at this stuff than me, preferably).
I install the 0.8.5.0 version and do all jordan's steps to solve the time zone issue but when I did this, the months of the calendar collapse, showing october after october and august before october. To solve this I change the calendar.php file in line 29:
$thisMonth = gmmktime(0, 0, 0, $month, 1, $year);
for:
$thisMonth = mktime(0, 0, 0, $month, 1, $year);
Now works ok, PP team, please find a solution for the time zone problem in the next release
Just want to add my two bob.
Version 8.0.3
In my case on the project Overview page in the Upcoming Milestones widget, the due date for upcoming milestones was one day more than it should have been. The number of days left was correct. In my case the timezone is set to GMT+10.
A quick hack was to open up application>views>project>overview.php and edit lines 73 and 75. Add ->getTimestamp() - 86400. See example
format_descriptive_date($upcoming_milestone->getDueDate()->getTimestamp() - 86400)
Still a problem in 0.8.6. Im in MST. The dashboard log shows the times correctly (3pm, 5:47pm MST = GMT-7 today), but the day indicator "Today", "Yesterday" is relative to GMT. Same for the milestone: it's due tomorrow Feb 10 (and in the UK it's already Feb 10).
I'm having the same problem as well. I tried some of the fixes above but they didn't work.
me too, subscribing