Current day is off by one - events are fine

Yes, I'm seeing this too - not only is the calendar off, but dates of submission are being recorded in GMT, even though the site's default timezone is GMT -4:00.
This is on three sites on two different servers - all running 4.7 or 4.7.1.

same problem here (GMT +2)

There is a patch to fix the submission dates but the calendar is still off. On my system the calendar jumps to the next day at 8:00pm EDT.

http://drupal.org/node/52481

Yes, i've been noticing this as well, but I'll check again tonight since I just updated to the most recent (2006-05-22) version of the module.

Still a problem- at 8:37 pm EST, the calender is showing today on tomorrow's date.

If your time zone is -5 you'll need to set it to -4 for daylight savings.

Ken

??? I do have it set to GMT -4. That is not the issue anyhow- the determination of what is "Today" should reference whatever time zone I have set, not GMT.

If the Drupal Archive calendar can show the correct date why can't the Event calendar do the same??

My guess is that this problem doesn't occur everywhere, or it would have been fixed already. The problem must lie with the following function, since this defines "now", or with the definition of "today" when generating the calendar. One thing to note, the "Today" mark is wrong in the calendar for me both when running on a server in PST (GMT -7) or a backup of that site on a server in EST (GMT -4).

/**
 * Returns a local timestamp based on the user or site time zone.
 * @return integer timestamp
 */
function _event_user_time() {
  global $user;

  if (variable_get('configurable_timezones', 1) && $user->uid && strlen($user->timezone)) {
    return (time() - date("Z")) + $user->timezone;
  }
  else {
    return (time() - date("Z")) + variable_get('date_default_timezone', 0);
  }
}

On second thought, the problem seems to occur in the _event_user_date() function:

/**
 * Returns a local timestamp (as defined by the user or site's timezone) for
 * midnight GMT.
 * @return integer timestamp
 */
function _event_user_date() {
  static $date;
  if (!$date) {
    $now = _event_user_time();
    $date = gmmktime(0, 0, 0, gmdate('m', $now), gmdate('j', $now), gmdate('Y', $now));
  }
  return $date;
}

Here's the evidence:

My site is set to EST (GMT -4). local time is 22:33. If I run this in a node w/ PHP format:

  print gmdate("M d Y H:i:s",_event_user_date());

the output is: "Jun 13 2006 00:00:00" --> WRONG.

if I run the following:

  $now = _event_user_time();
  $date = gmmktime(0, 0, 0, date('m', $now), date('d', $now), date('Y', $now));
  print gmdate("M d Y H:i:s",$date)."<br>";

the output is "Jun 12 2006 00:00:00" --> CORRECT.

I'm still befuddled by gmmktime vs. mktime, gmdate vs. date, etc.

Patch attached- try it for yourself...

pwolanin, I tested your patch and works fine.

I am in GMT +1000, and I experienced the one-day ahead problem in the events calendar. After applying the patch today's date now shows correctly. It also ticks over to the following day at midnight local time. To me this suggests your patch fixes the problem.

Ok, I'm setting to RTBC- I think the patch corrects the problem cleanly.

I want to apply this patch, but I also wanted to share that the problem may be more messy than it appears, with jscalendar and scheduler being the other culprits. This might suggest be a larger problem with drupal itself.

I am in GMT+5.30, it is about 15 min past 8.00 a.m here on 19th August, but here is what I am seeing:

Without JS calendar

1.) The event date/time fields are showing 17.43 on 20th August (36 hrs. ahead)
2.) The scheduler date/time fields show Format: 2006-08-19 22:43:59., nearly 14 hrs ahead of my current time.

With jscalendar

1.) The event date/time fields show 2006-08-20 17:08, 36 hours ahead of schedule
2.) The scheduler shows Format: 2006-08-19 22:47:40. in the description text below the calendar icon, nearly 13 hours ahead of my current time. But- and this is most interesting- the calendar itself shows 08:18 on 20th August, a full 24 hours ahead of my current time.

Interestingly, scheduler has a drop-down field that always shows my timezone correctly- the one that I configured in settings.

I was also having the same problem with GMT +9 for the event displaying a time as a day ahead. After I changed the event's settings in the administratio panel to:

• Use the time zone of the user editing or creating the event
• Use the event's time zone
• 12h

the problem went way. Now everything shows as I originally wanted. Although I set the time to 12h display, it still shows as 24h (which is what I prefer). I am using JSTools.

The other problem I should create an issue for, is when editing a node, the start and end times replace the minutes with 08, so if the time was 17:00, while editing it changes to 17:08. I haven't been able to trace the problem.

myriad, I think you changed the title of the issue unintentionally. Changing back so that we don't lose track.

Ramdak, can you please test the patch without wither jscalendar and scheduler? Your setup seems to be the best to test this...

I will. Is it the patch at comment #11?

yes, the patch is from #11

Thanks. That has a .txt extension. I suppose I should rename it before running the patch?

At least for me, I run it as "patch -p0 < patchfile", so patch doesn't even know/care about the filename.

Sorry if I am being dense, but do you mean I can leave out the .txt extension or are you referring to the patch command syntax?

duh, sorry I meant : "patch -p0 < patchfile", so when used this way the filename is irrelevant. In any case, I don't think patch cares about the extension.

Thanks. Going to try the patch now.

I applied the patch but the problem hasn't gone. Screenshots follow.

I am in GMT+5.30 (11.30 p.m approx on 6th September). Time shown is ahead by about 9 hours (acutally shows the next day).

Settings

• Configurable timezone disabled
• jscalendar disabled

Correct date now, but behind by about 1.5 hours. Configurable time zones now enabled.

Configurable timezones *disabled* again, but js calendar enabled. Wrong date and time again. Ahead by a day (9 hours)

Configurable timezones enabled, jscalendar enabled. Correct date this time, but behind by 1.5 hours.

For what it is worth, here are screenshots of the scheduler with jscalendar enabled.

This time with configurable timezones disabled. Correct date (6th sep) but behind by nearly 9.5 hours

Scheduler after event module patch with config time zone enabled and with jscalendar.

At last!! jscalendar shows the correct date and time!! The time shown beneath the form field is still wrong, though.

Funnily, this is on the same event node form where event.module shows the wrong time for me despite the patch and despite config time zones being enabled.

Hope this bit of testing helps.

The two other variables I tried unsuccessfully were, a.) setting event time zone display to the event time zone input (use the site wide time zone) and, b.) using 12h instead of 24h notation.

I still wonder if it might be an underlying drupal issue rather than an event/jscalendar/scheduler issue. This seems to be borne out by scheduler showing wrong date and time beneath its fields, but jscalendar showing the correct details.

I read Rob Thorne's posting about drupal timezones yesterday. I am sure people have seen this, but might be worth a second look:
http://www.torenware.com/handbooks/timezones

The only thing this patch is trying to fix is when the "today" setting jumps ahead to the next day in the calendar display. Take a look- it's only a single line change that changes the return value of function _event_user_date().

_event_user_date is only used in display functions: event_calendar_month, event_calendar_week, event_calendar_day, event_calendar_table, event_calendar_list, event_get_calendar, and event_block. It is not used at all in function event_form_alter.

So, this patch will not change anything in the drop downs, etc. If you are having problems there, the relevant functions called in event_form_alter are _event_date, _event_user_time, and event_form_date. However, that would be a different bug.

Thanks. Yes, I noticed that the patch file made only one change.

But, that doesn't seem to have helped as #26 and #27 show. With configurable timezones disabled, the event date is still ahead by a day and with it enabled, the date is correct but the time is behind by a few hours.

I think there may be more than one bug. For me (no JSCalendar, using the site-wide time zone) the event dates and times look fine, but the "today" in the calendar view jumps ahead to the next day early by the number of hours i'm off GMT. The patch in #11 fixes this for me, using event.module,v 1.183.2.6 2006/05/22

I've applied patch #11 to my new install of the event module (// $Id: event.module,v 1.183.2.8 2006/08/23 20:00:03 killes Exp $ ) and I'm still having an issue with the date being ahead by one day when it is an upcoming event but the correct date displays when I click on the node to view it in its entirety.

So the patch doesn't work for my new install. I've also tried enabling user configurable time zones but that doesn't fix the problem either.
Lsabug

As far as I know, this patch doesn't affect the display of events, it only determines which day in the calendar to mark as "TODAY". The issue I'm interested in this bug report in solving is whether the correct day in the calendar is marked as "TODAY".

One interesting data point. I've been playing with alternate formats for the upcoming events block (http://drupal.org/node/78271). My times are correct under Windows XP (XAMPP) but lacking timezone corrections on my Unix host (FreeBSD). One possibility is that my WinXP laptop is (of course) set to local time while the clock on my server is set to GMT.

FYI, as a nasty hack until this is fixed, I hard-coded a timezone offset into my upcoming events block.

/**
 * Format an individual upcoming event block item
 *
 * @param node
 *   The node to render as an upcoming event
 */
function theme_event_upcoming_item($node) {
  $output = l($node->title, "node/$node->nid", array('title' => $node->title));
  $output .= '<span class="event-timeleft">'. gmdate('D, F j, Y', $node->event_start - 25200) .'</span>';
  return $output;
}

Now, the odd thing (as others have noted) is that the timezone offset is correctly applied in the events list and the node itself. Something about when or how the upcoming events block is called loses the offset, and this is true for both $node->event_start (which I call in my customized version)and $node->timeleft (in the original code).

Apparently this patch doesn't fix the issue in all cases.

My problem is that my server is in Australia, hence the one day off. Is there a way to manually specify timezone in Drupal instead of calling it from the server?

I spent a fair bit of time on this and I think I have an explanation and a solution for the miscalculation of the current date on calendars. It's complicated, so I have a long-winded explanation and a patch. The patch is also kind of complicated and maybe once the issue is understood someone can find a way to make it neater.

The problem is that everywhere the event module is trying to determine what 'today' is, it is doing it by comparing _event_user_date() (the time it is for the user at midnight GMT) to a timestamp which is set to midnight of a calendar day. Those two values are not always in the same day, and the problem occurs if you try to calculate what 'today' is for the user during the period when the user is in a different day than GMT, a situation which will last for the length of the timezone offset.

The reason why the previous patch would often, but not always work, is that it changed gmdate() to date(). The difference between gmdate() and date() is the timezone offset of the SERVER, so it had the effect of adjusting the day calculation by that amount. If the server and the site and the user are all in the same timezone, that fix should work. I believe it will also work if you do not use configurable timezones, since all times will reflect the timezone offset of the server in that case.

The problem is if you have the site timezone set to something different than the server, or if the user has selected a different timezone. In that case, adjusting for the server timezone offset won't be the right fix. So the right fix is more complicated. You have to figure out if there is a difference between 'today' for the user and 'today' for GMT, but you have to do it by figuring out which timezone offset applies and using that offset rather than just using the server offset.

This fix may introduce other problems if there are places in the code that use _event_user_date() for comparing or setting any time of the day other than midnight GMT, since this change will not work right in those situations. I tried to see if there were any places where this was happening and didn't see anything obvious, but timestamps are often passed from function to function so sometimes it's hard to tell what date is being used for comparison and it's possible I missed something.

I attached a patch to adjust the result of _event_user_date() for the timezone adjustment and also to fix a related problem. That problem is the way that the 'selected' day is identified (as opposed to the way 'today' is identified). That is done by checking the day of the calendar day midnight timestamp against the requested day in the url, and that again could be off for the same reasons mentioned above. The easiest way to fix that is to use the now corrected 'today' value to get a day and test the requested day against that value.

As noted above, this has nothing to do with any jscalendar issues and has no effect on the actual node view, which is why the times look OK when viewing the event.

And again, the patch may be (probably is) unnecessarily complex, but I have spent a lot of time on this already and I've run out of steam :-)

My formula was on the right track but not quite right. This is a better and somewhat simplified patch. You can see that I'm testing for how far 'now' is from the midnight GMT date we're comparing to, and deciding based on that whether or not to adjust the day.

Nice one, you rock Karen. About to hit the hay but I'll check this out the next change I get.

Thanks for all your hard work,
Alex

Marking this to get reviews

working on reviewing the patch- 2 minor concerns with the patchfile itself. Seems to have been made against HEAD, rather than the 4.7 branch, and diff doesn't have the -p or -F^f flag. given that- it applies cleanly to the 4.7 branch (rev 1.183.2.10) with offset.

Testing this patch, I get immediately a problem where "today" jumps ahead an extra day all together when I set the site timezone to something like GMT -2, which is ahead of the server timezone. This is on a site with per-user timezones disabled. The server is GMT -5.

I'm going to review the patch later today.

I appreciate the analysis that KarenS has done, but let me take it one step further, towards the root cause.

The underlying cause is related to the error in documentation for these functions (_event_user_date and _event_user_time). They both say "Returns a local timestamp..."

There's no such thing as a local timestamp. Timestamps are always UTC. (See Rob Thoren's write up, cited above in reply #32.) What it's trying to say (for _event_user_time) is "returns a timestamp that corresponds to the point that Greenwich, UK would be at if the time there were actually the user's current time." Pretty clunky, isn't it? I tried several alternatives, none good. Perhaps the best might be to say "If it's 16:23 in the user's time zone, this returns a timestamp for 16:23 UTC," but that doesn't really help to use it.

This just shows that the underlying design is wrong. It's not correct to pass around timestamps that have been adjusted for the time zone, because timestamps are intended to be absolute. Adjusting them this way is going to be error-prone and hard to maintain (as this thread shows). The proper place to do the adjustment is whenever the timestamp is converted to a textual representation, and no sooner.

I take back what I just said (sort of).

Digging deeper, PHP versions prior to 5 don't provide a robust method for taking a time zone and a time stamp and producing a string representation of that time stamp for the given time zone. (It's essentially limited to changing the TZ environment variable, but there's no guarantee that that's possible.) Even PHP 5 is a bit bogus in this regard; it still doesn't permit an explicit time zone parameter.

Adjusting the timestamp is a bit of a hack - getting it totally right is damn hard. But it seems to be the best approach for as long as Drupal has to support PHP 4. The internal documentation will need to be much clearer, though.

One problem right away with event.module_47.patch is that in event_calendar_month, it's using the current day (i.e. gmdate('j', $today)) for the selected class, but the selected class represents the day of the event, not today. At a minimum, it should be gmdate('j',$day) instead. There are other problems in this function that ought to be fixed (like not initializing $week), but those aren't related to this patch.

I keep getting back to the following: The intuition in reply #10 was correct, i.e. the problem is in _event_uesr_time. Reply #11 is wrong because it just worked around the bad timestamp it was getting from _event_user_time, and as a result, didn't work if the user's zone wasn't the same as the system's zone.

The error in _event_user_time is the subtraction of date("Z"). The time() function returns the current time; this is absolute, with no associated timezone. Adjusting by the user's time zone gives you a timestamp such that using gmdate on it will give you the correct answer for the user's time zone (and not the current GMT time). Adjusting by date("Z") adjusts by the system timezone - but the system time zone is totally irrelevant to the calculation of time(), and hence has no role to play here.

Here's my current version of _event_user_time. I haven't finished doing a full review and test of it, but I figure it's worth sharing at this point.

/**
 * Returns a timestamp based on the user's time zone.  If the user's time zone
 * isn't configured, then the default time zone for the site is used.
 *
 * The timestamp is adjusted so that if you use the gm conversion functions 
 * on it to get text, the result will correspond to the user's time zone.  It's
 * done this way because there are no PHP 4 mechanisms to generate text from
 * a time stamp that take a timezone parameter, and we don't want to change the
 * TZ environment variable.
 *
 * @return integer timestamp
 */
function _event_user_time() {
  global $user;

  if (variable_get('configurable_timezones', 1) && $user->uid && strlen($user->timezone)) {
    return time() + $user->timezone;
  }
  else {
    return time() + variable_get('date_default_timezone', 0);
  }
}

We downloaded Drupal 4.7.4 on 4 Dec 2006 and have been customizing it. We added Views, Events, Calendar, Feedback and SimpleNews, and they all seem to work fine. We didn't notice this issue at first, but on our test site which is on a server in the Central Time Zone, the Event module all seems to work except the mini-calendar that shows up on the front page, on that one, the date changes 6 hours before midnight to the next day.

On the real site which is on a server which is on Pacific Standard Time it changes at 4:00pm, or 8 hours early to the next date. (at least from machines that we are using here in the Central Time Zone)

I think this is the issue that this topic is talking about. When you get to the actual calendar the events are always posted correctly, and on the posted byline it always shows that time correctly, it's just the front page mini calendar that changes dates early.

We have tried applying the event_date_patch_0.txt patch from #11 above, but can't get the cygwin utility to patch it, though we were able earlier to apply a patch to the profile module which fixed it's issues.

We haven't tried the other patches yet, but we wonder if there's been any further action about this issue?

It seems odd that the mini-calendar for Archives which shows up on the same front page always changes at midnight on both the test and real site, but the event one seems inexorably linked to Greenwich Mean Time (or something) somehow.

Thanks in advance for any advice.

Should have mentioned in earlier post: the highlighted day is wrong in the big calendar as well as the minicalendar.

We did apply the event.module_47.patch, the patching process itself went fine, but now the test site thinks it's yesterday instead of tomorrow.

If only there were an option in Administer-Settings-Event to hard select the timezone that the Event Calendar lived by.

Pleading for any new suggestions . . .

Will this problem ever be fixed? I just downloaded the HEAD version for Drupal 5 and the problem still exists. Sorry, but this is hard to believe!

I will continue to test but in 4.7.4, replacing the _event_user_time function in event.module with that contributed by Gary in #49 has solved the issue for me for now. Thanks!

Of all these patched, #49 was the closest to a fix. If you are debating how to handle this problem for sure give #49 a try.

Sorry, perhaps this isn't the place to ask, but where exactly in the events.module do I put the lines in #49, and what do I have to delete?

Hi everyone,

I don't know whos looking after this but this thread is insanely long. I just wanted to say that I have also had the same problem using 4.7 module and that the function posted in #49 seems to of fixed my problem as well. Someone please integrate this into the main source.

Thanks for the help everyone.
- Vince

Problem also occurs in 5.x-1.0. Applied patch #49 as suggested and it fixed my problems.

Oddly enough however... now when creating an event I am -0700 off when displaying the current date/time (which is my time zone). In the calender view however, it highlights the correct day.

Sounds like the fix doesn't belong here but in the function that produces the calender time since it's an isolated problem to the calender view in 5.x.

I am very much inclined to mark thi mess "won't fix". people having problems here should try the 5.2 version which does away with timestamps.

killes,

You mean the 5.x-2.x version?

I'm being hit by this too, so I'll give that version a try this weekend. Good thing my site isn't live yet, though I'm not so sure that this issue is critical per say.

yes,

The problem lies in the check on whether or not to use a user-defined timezone or not.

function _event_user_time(){
  if ((variable_get('configurable_timezones', 'site') == 'user') && $user->uid && strlen($user->timezone) && false) {
    ...
  }
}

it used to read variable_get('configurable_timezones', 1) .... which will always be a true statement since that variable is a string value (site, user, or input). if you check for 'user' like it wants to and default to 'site' like the variable is by default, not a numerical value, then it all works out nicely if you've configured event to take the site's timezone

Killes,

Is the 5.x-2.x version ready for a live production site?

Am trying the 5.x-2.x version on a live site in attempt to stave off a user revolt.

I also have this problem, but it only happens at night, I'm in the East coast and when a user is logged in, it uses the user timezone, but for anonymous it off for hours, I checked the timezone setup for the whole site and it's setup for East coast time.

In other words it shows the right day for logged in users but not for anonymous.

I'm using PHP4 and Drupal 5.10.

Any suggestion?

This does the trick, how come every update come out this way?

I went in and did it manually!

event.module

- $date = gmmktime(0, 0, 0, gmdate('m', $now), gmdate('j', $now), gmdate('Y', $now));
+ $date = gmmktime(0, 0, 0, date('m', $now), date('j', $now), date('Y', $now));

stop using php4 and get php5 up and running.

I'm still having this issue and not sure a) which fix solves the problem, and b) is it a cache problem or a date problem, or a timezone problem?

Ack! Can someone point me to the right fix? I have 3 sites to patch!

Thanks!

#49 did it for me.

Please don't change the title unless it better states the issue.

Event for Drupal 8 is unrelated to older versions. If an issue similar to this one exists, please open a new issue with the 8.x branch.