Several issues (links to follow) report an event problem - the calendar jumps ahead either by a) a few hours or b) a day. If this happens at the end of the month then not only the day, but month, is wrong is calendar views.
http://drupal.org/node/39193 #17 (from macgirvin) seemed on the right track with his assessment that event.module sometimes is using a 'corrected'/'offset' time, and sometimes is using GMT.
In http://drupal.org/node/29392 hunmonk cautiously hypothesizes that, contrary to expectations, event.module does NOT, repeat, NOT store event timestamps in GMT, but rather in site default.
Well, I believe both are correct. And this simple-ish change to event.module fixed the problem for me. Knock wood.
The problem was as follows:
- events in node view were showing the correct start and end times - so nodes were on Site Time, but...
- calendars (in month, week, table and list views) were consistently jumping ahead to the next day x hours too soon ( x hours being my site timezone offset). In other words, calendars insisted on GMT.
In event.module function event_page() -> line 198, v 1.122.2.26 2006/02/24, the function first creates a variable called $now based on _event_user_time(). In other words, the site or user adjusted time. Then, the function creates a 'request timestamp' by converting $now to GMT through the use of a batch of gmmktime and gmdate calls. The new variable is called $stamp. This would be the correct procedure - IF events in {event} were stored as GMT timestamps. But they're not!
So - I replaced the gmmktime/gmdate generation of $stamp and its derivatives with plain mktime/date versions, which do the same thing (create date strings) but don't convert the given timestamp to GMT in the process. So far all my calendar views seem perfectly aligned with site time, and event nodes are still displaying correct start times.
In event.module, lines 204-207, replace the existing four lines with these and see if you have the same good results:
$stamp = mktime(0, 0, 0, ($month ? $month : date('m', $now)), ($day ? $day : date('d', $now)), ($year ? $year : date('Y', $now)));
$year = date('Y', $stamp);
$month = date('m', $stamp);
$day = date('d', $stamp);
If anyone feels like testing this and reporting back I'd appreciate it.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | event_0.png | 41.97 KB | sam moore |
Comments
Comment #1
nydrupalfan commentedI'm having a problem with the cvs (from several weeks ago) event module. When I attempt to change the site timezone to match EST daylight savings time (was GMT -5, now is GMT -4), the start times for all the prior events are off by an hour. Do you think this code patch would fix that problem? Also, would current events have to be re-entered to be stored with the different timestamp?
Thanks!
Comment #2
chromeyellow commentedHaven't looked at cvs/4.7 yet, but I will soon and report back. But your issue may be related to this one.
And I should revise my diagnosis. I said that event shows (correct) timezone-adjusted times for events in node views, but that the overall calendar views (month, table etc) stay on GMT. That's not quite right: it seems that overall views apply the timezone offset twice, instead of once, which is why the calendar view can get out of synch with your actual time. And this (tentative) fix stops that from happening.
Ouch. Event is great but head-hurting. Sorry I can't help but as I said I'll catch up to cvs event-ually.
Comment #3
dude4linux commentedI've been seeing similar behavior using 4.6, but haven't had the time to dig into the problem. Now I won't have too. Thanks for the fix.
Dude
Comment #4
nydrupalfan commentedThis patch rocks! I just tested it on CVS and it seems to have fixed my timezone issues at first glance. I was able to change the site timezone to account for DST and it didn't break the event start and end times.
Could someone else test this and then get it committed?
Comment #5
nydrupalfan commentedWhile this patch works great for the website, some of my events are randomly off by an hour when subscribing via iCal. Not sure if the problem only occurs with events stored prior to applying the patch, I will try to test that more thoroughly.
By the way, is anyone actively maintaining this module anymore? Lots of patches/bug reports are piling up.
Comment #6
DrLou commentedI have tested this - under 4.7rc4, with no luck.
We were having a similar problem: Entered events are displayed offset by 1 hour - looks like a DST offset kind of error.
Proposed code changes were made at roughly line 190 in the cvs event.module.
Help!
Comment #7
sam mooreSame problem here. Patched event.module around line 190 or so, thus (commented out the old code for comparison):
// create request timestamp and date values
// $stamp = gmmktime(0, 0, 0, ($month ? $month : gmdate('m', $now)), ($day ? $day : gmdate('d', $now)), ($year ? $year : gmdate('Y', $now)));
// $year = gmdate('Y', $stamp);
// $month = gmdate('m', $stamp);
// $day = gmdate('d', $stamp);
$stamp = mktime(0, 0, 0, ($month ? $month : date('m', $now)), ($day ? $day : date('d', $now)), ($year ? $year : date('Y', $now)));
$year = date('Y', $stamp);
$month = date('m', $stamp);
$day = date('d', $stamp);
But no luck - date in calendar is still off by 1 day.
Also, interestingly, the "Date Format" selections at administer->settings are displaying GMT, even though my site-wide timezone is set to GMT -4.
Anyone?
Comment #8
sam mooreSorry, i should have waited a little longer - that patch did in fact work (I think something was cached).
thanks for the fix!
Comment #9
sam mooreOK, this is odd:
the main calendar view highlights today in blue and tomorrow in pink. Anyone know what this means?
the little calendar in the block highlights tomorrow only.
See .png attached.
Comment #10
mjohnq3 commentedI applied the above patch (changing gmmktime to mktime etc.) and the calendar shows the correct date until around 6pm to 7pm EDT when it jumps to the next day! Right now (5/19 at 10pm EDT) the drupal archive calendar shows 5/19 as the current date while the event calendar shows 5/20 as the current date. Very strange!
Comment #11
killes@www.drop.org commentedno proper patch file
Comment #12
kowalke commentedDidn't work on my 4.6 installation. There was no seeming change.
Big bummer.
Comment #13
chromeyellow commentedSwitching version back to 4.6 because this possible fix isn't designed for 4.7. Waiting for the dust to settle wrt to a stable "date" object etc as mentioned in other threads.
No patch file yet. I should emphasize that though this hack seems to work, it actually _shouldn't_ work! It works because the event timestamps may not be saved correctly - ie with the advertised timezone shift. So the alternate approach is to fix the saved event timestamp, in which case the original code - and not this hack - would once again work.
Comment #14
chromeyellow commented