Date problem on calendar, off by GMT offset

I wonder if the server's clock is set to GMT... That would explain the even -8 hours, that's the west coast offset to GMT. Do you know what OS the webserver is running? Unix or Windows?

try setting the server timezone to GMT, then set the default user timezone to -5.

I'm no expert in these matters but I don't think Jeff's problem stems from the server. I'm experiencing the same exact problem but with a difference in operating variables. Where Jeff's server is set to Western Time (-8) my server is set to Eastern Time (-5).

Sever info:
PHP: 4.4.1 as cgi
Webserver: Apache/1.3.33 (Unix)

Jeff: Where in event.module did you place the code?

This appears to be part of the same problem so I'll list it here - the archive calendar was off by one month. Only on the first day of the month (12/1/2005), and only when navigating to last month (November 2005). November 2005 did not show up at all in the navigation. October 2005 showed up as the headline for the November calendar. It did not contain a forward link. Stepping backward through time, the displayed months were all off by one - i.e. Jun-2005 had a forward link to 2005/08 and a backlink to 2005/06. It should've said July.

I should also note that my timezone is GMT-8.

The 'today' highlight was correct in my case. But I'm filing under this bug because it's all the same problem - the drupal archive calendar is getting confused precisely what day it is under some complex circumstance.

Doing some checking of stuff I discovered that previous and next month links are calculated correctly. What seems to be malfunctioning is the calendar headline month coming from a format_date function in archive.module. Unfortunately by the time I narrowed it down to this point, it was just past midnight (December 2, 2005 00:02) and everything started working correctly again.

in archive.module: look for
format_date($requested, 'custom', 'F') . date(' Y', $requested) where it's spitting out the top bar of the calendar.

I did not have the opportunity to check if the timestamp in $requested or the formatting options were to blame. $month, $day, and $year from the arg list seemed to be correct - so either $requested is not getting the proper result from mktime or it is not being converted correctly in the format_date call.

To reproduce, set the system time back to 12/1/2005, use a system timezone (like GMT-8) and navigate to last month using the arrows on the calendar. Should say November, but in my case it doesn't.

I'm wondering if the "day" issue is caused by event_timezones.inc. I noticed that - in a list view - events have the stamp "Timezone: Etc/GMT+5", shouldn't it be GMT-5 for the Eastern Time Zone? I may not be following the logic correctly and the offset is meant to make everything default to GMT but either way, something is afoul because the problem occurs at exactly 7:00 pm (19:00 hrs) Eastern Time. 19:00 + 5 hrs = New day.

Make sure that you're running the latest version of the event.module. That negative timezone bug is/should-have-been fixed: http://drupal.org/node/29768

drewish:

Thanks for the tip. When I tried to apply the patch I got a message about it already being applied so I "installed" event_timezones.inc,v 1.1.2.4 dated 2005/11/28 (had event_timezones.inc,v 1.1.2.3 dated 2005/06/30 installed previously).

Well that fixed the problem with "Timezone: Etc/GMT+5" but I'm still searching for a solution to the "bigger problem". It is 7:31 pm Eastern time here (19:31) and the Event Block states that the current date is Dec. 3rd when it should be the 2nd. :(

I really appreciate your help and if anyone else would like to jump in and suggest a solution please do. I'll try anything. The event module is important in our application with drupal.

Incidentally all of our users are on the Eastern Time Zone.

Same problem. I accidently created a duplicate of this issue (sorry). I'm running 4.6.3 and I'm using the latest 4.6 download of the event module (with the basicevent.module). The current day is incorrectly shown as tomorrow's date! To me this is a critical issue, because if a calendar is unreliable, it really can't be used (creates more confusion than its functionality or aesthetics warrant).

I did a little poking around and got the same problem. Here's a patch against 4.6 that seems to fix it for me. Could you give it a try and let me know how it works?

Here's the patch for HEAD.

Humm, the 4.6 patch didn't seem to attach.

Well, that HEAD patch didn't attach either.

I applied the patch but unfortunately it's well after midnight eastern time so I won't be able to tell you if it worked until later this evening. btw I got this message:

(Stripping trailing CRs from patch.)
patching file event.module
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 464 with fuzz 1.

Nothing about Hunk #1. I'm not sure if the patch even did what it is supposed to do.

Thanks again for all of you hard work and dedication.

Chris

abnaki, I'm glad to help. It's an important module that needs more attention than it's getting.

I'm not sure quite what that error/warning means. I guess if the patch doesn't fix the problem I'll look into blaming it on that ;)

No luck with the fix, the event block/calendar still shows the wrong date. :(
Just so we're all on the same page:
Downloaded the patch file attached to #13. Used shell access (putty) to patch the file. Used this command:
patch event.module < event.module_selected_day_off_by_one_4-6.patch
Received message:

(Stripping trailing CRs from patch.)
patching file event.module
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 464 with fuzz 1.

well, here's my latest try. hopfully you'll be able to test it tonight.

make sure that the block calendar looks right and that the right time comes up when creating a new event. if it works i'll roll another patch for head.

actually, abnaki, don't bother with that last patch. while it mostly works on the current month it also, incorrectly, highlights days in previous months. i don't see an easy way to do this. i think it's going to take some hacking.

I'm seeing this problem as well, with Central time. Also another problem I'm noticing is that when I have user timezones turned off in the main settings page, I can't switch the event_timezone_display to 'site' -- it's always stuck at 'event' and even modifying the database manually yeilds no results (it just automatically switches it back to 'event'..)
I can switch it once user timezones are enabled, but as soon as I switch them back to disabled it switches itself back.

Legoguy, open a new issue for that bug (if one doesn't already exist).

I am also having this problem and neither the patch posted here nor the fix mentioned in http://drupal.org/node/29768 or a combination of both fix the problem. I tried hardcoding the time as mentioned in update #1 - it will highlight the right day, but still think it's the wrong day.

Nope. I'm sorry. The hardcoding did work. Darn that cache!

New Drupal site in development, + I too noticed one day later highlighted as current day, but hadn't yet investigated. Now in testing something else in event module, I see that this day later highlight only happens in Safari (!), not in handfull of browsers cross platform. How strange is that?

oops on previous confirmation, due to not being logged in, + time zone settings. Apologies.

I've looked at these patches - adding eight hours to the time is a patch but not a solution. This also has nothing to do with the other referenced bug of having negatively applied offsets. It appears that the problem is due to a large number of mktime calls in the calendar code (archives and event). Some of these calls are corrected for timezone. Some aren't. Then they are mixed and matched together without regard to whether the timezone was corrected or not. I'd probably throw out the calendar (both of them) and start over. The only thing you need a mktime call for is to tell you what day the month started. But if you're going to correct the results, do it consistently. It appears from my casual observation that all the events (or marked information) in the calendar are corrected for timezone, but the calendar itself is not. The entire calendar (not just the events) should be represented in the appropriate timezone.

This isn't something just on the calendar, but it's also affecting the upcoming block as well. All my events which are occuring "today" don't show up on the upcoming block at all, which is actually pretty confusing because it looks like nothing is happening today. None of the patches posted in this thread helped the matter either. I'm running 4.6.something.

I just noticed a similar problem in the upcoming events block on one of my sites (http://www.lvchs.org/). Events with later start times were showing up on the next day. My server is on a virtual host. The physical server is in California, but I've got all of the time zone info set correctly.

I noticed that there is a general "bug" with the way php's gmtime() function behaves and my modified theme_event_upcoming_item($node) function now looks like this:

return l($node->title, "node/$node->nid", array('title' => $node->title)). '<span class="event-timeleft">('. gmdate('Y-m-d', $node->event_start+date("Z")) .')</span>';

Previous to this, the '+date("Z")' was not there.

This immediately rectified the "which day is it really on" issue I was having.

Hope this helps someone.

Our upcoming event block doesn't show the remaining days correctly and your behaviour is not coherent.

Our intranet runs on a local linux server machine, local time is GMT-2 and the event module is v 1.122.2.23 2005/10/04. Drupal version is 4.6. We use Firefox.

I don't know PHP yet but I think our problem is not related with local time because when an event happens to < 1 day (< 24h ) the number of hours remaining to that event is showed correctly. In that situation, it runs well.

So, it seems there is 8h in advanced because in our real situation (on intranet) happens this:

--> "today" is 17/02/2006 and the next event is 22/02/06 (start time - 8:30h)
--> I accomplished this situation: the current time of "today" was changing: 8h ... 11h ... 14h and the days remaining showed was "5" in each situation... it´s correct to me (22 - 17 = 5).

But

--> when the current time was 16h ("snapshot" in attach), the days remaining to that event was changed to 4 days. So it seems the system "thinks" the present day is changed 8 hours in advanced like the problem described in this post. It´s wrong to us as well.

BUT, consequently, if the event module "thinks" current day is advanced, it would be "5" the number of days remaining to the event of next day (23/02).

However, the upcoming block shows "6 days", it is not coherent despite to be correct in my vision (23 - 17 = 6).

Concluding: an event have "days remaining" in "advanced" and other event (on next day) have correct "days remaining".

My self-question was "what's happening?" Ahahhhh... There is a difference between 23/02 and 22/03 events in your start times. Event on 23/02 have set start time = 18h and event on 22/02 have the start time = 8h30AM.

So, it´s seems calculation of days remaining depends on start hour of events as well.

In attach, the problem happening in a "snapshot". Local time is 16h, "today" is 17/02/2006.

I tried the simples solution proposed by #29 - hrbrmstr and it doesn't run, a PHP error is showed, but that solution will be sufficient to all (because of not coherent behaviour above reported)?

I need only to do this calculation (visualize a calendar on desktop):

1) if event < 24h, it must continue as is, because it runs perfectly.

2) if event > 24h, days remaining would be calculated like I count using my finger pointing to calendar. If today is day "17" and the event is day "22" of same month, days remaining would be 22 - 17 = 5. (All person did that "analogic" calculation). It's obvious it is necessary to take consideration the different number of days of each month when events are situated in different month from actual.

So, if event > 24h, I don't need to take consideration both times: start time of event and my current time ('today").

Any ideas about this relate? Or someone can give me a short explanation about the variables used by event module to this calculation taking in consideration the date/local time? With those informations, I can try to resolv.

I think this is a critical bug because persons see calendar with events in day after tomorroy but the upcoming block says "1 day". They are confused.

Thanks in advanced.

submitted by hrbrmstr on February 3, 2006 - 04:08

I just noticed a similar problem in the upcoming events block on one of my sites (http://www.lvchs.org/). Events with later start times were showing up on the next day. My server is on a virtual host. The physical server is in California, but I've got all of the time zone info set correctly.

I noticed that there is a general "bug" with the way php's gmtime() function behaves and my modified theme_event_upcoming_item($node) function now looks like this:

return l($node->title, "node/$node->nid", array('title' => $node->title)). '('. gmdate('Y-m-d', $node->event_start+date("Z")) .')';

Previous to this, the '+date("Z")' was not there.

This immediately rectified the "which day is it really on" issue I was having.

Hope this helps someone.

Where did you make that modification exactly?

[code]function theme_event_upcoming_item($node) {
$output = l($node->title, "node/$node->nid", array('title' => $node->title));
if ((event_get_types('all') + event_get_types('solo')) > 1) {
$output .= ''. t("($node->typename)") .'';
}
$output .= '('. $node->timeleft .')';
return $output;[/code]

That's the instance of function theme_event_upcoming_item($node) that I found in event.theme.

I can't see anything similar to
[code]return l($node->title, "node/$node->nid", array('title' => $node->title)). '('. gmdate('Y-m-d', $node->event_start+date("Z")) .')';[/code]

Can you (or someone) elaborate?

Many thanks.

You discovered exactly the correct place. It´s likely the author changed the code to the upcoming block doesn't show the type of content relative to each event (he deleted the statement "if").

At following, he "join" the two lines of "output" in one.

$output = l($node->title, "node/$node->nid", array('title' => $node->title));
and
$output .= '('. $node->timeleft .')';

The proposed solution modifies the second output which do a new calculation to show the remaining days (or hours) to the events. But for me it happened a PHP error.

And now more one "report" about this issue.

At this night, I had the following situation: (see the attachment)

"Today": day 20, local time=1:15AM.
Next event: day 22, start time=8:30AM.

So, the upcoming block event would must display "2 days" (22-20) in my vision, but again it was incoherent. It showed "3 days" and this is incredible because in previous post (#30) it seems "today" was increasing 8 hours.

I have a similar problem. I am on the east coast of Australia and therefore GMT +1000. Events added display correctly on the Event Calendar and also on the Upcoming Events list. The number of days and hours till next event seems to be OK as well.

Where the problem is, is that the highlighted day for "today" does not display correctly until 10am on that day. ie it highlights "yesterday" as "today" until 10am, then displays the correct "today". Does everyone follow :-)

This appears to indicate that the highlighted day does not read the timezone correction, and only displays "today" in GMT. No good.

The site is hosted on a FreeBSD box at my ISP and the server is set to GMT +1000.

I have set Drupal to use sitewide time setting.

Does anyone in eastern Australia have the same problem or have a fix?

Having the same problem (i.e. off by GMT offset). Using Drupal 4.7 and Sept. 18th build of event module on MacOS X. Date and time zone on server set correctly.

Hack in #1 above seems to work; hoping to see a proper fix for this bug though.

I am also having this problem. The solution in #1 (hardcoding an offset on line 1371) does not seem to work in this case. The system date, hardware date and time zone are all set correctly on the server. This seems to be a major issue. Is there anyone for whom this module works correctly?

See if the patch at http://drupal.org/node/65210 fixes the problem. I think it might.

This version of Event is not supported anymore. The issue is closed for this reason.

Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.