Scenario: an event is meant to happen every second Saturday. When creating the event, the event repeat settings are as follows:

  • Repeat Type: Daily
  • End settings: some date sufficiently far into the future
  • Advanced Interval: 2
  • Advanced Day(s): Saturday is selected

The first event in the sequence appears on the correct date. Each following repeated event is meant to occur every second Saturday, but instead appears, at the correct time, every second Friday.

We're running 5.7, all contrib modules are up to date, MySQL 5.0.51a, PHP5.2.5.. any insight would be greatly appreciated.

Comments

seanbfuller’s picture

This may be an interface problem. Try setting the repeat type to weekly and see if that helps. Otherwise, what is your site time zone set to and what is the time for the event?

Adduc’s picture

I'm doing using a weekly interval, timezone -5:00 on Pretty fresh Drupal 5.7 installation. Trying to create a recurring event, the first day goes in successfully, but every occurrence following is placed a day prior to what the original was set at.

Upon editing any of the errored dates and saving, the days they occur is pushed one day prior to that, now making it two days off the supposed dates.

seanbfuller’s picture

At what time are these events happening? (1:00, 12:00, 16:00, etc.)

Draggan’s picture

Version: 5.x-1.x-dev » 5.x-1.1

same problem here.
eg.
WEEKLY BYDAY=TU,5TU
MONTHLY BYDAY=1TU
some or all repeating events appear one day too early. (i have more than 120 repeating events here)

interestingly you can't even edit the event to set the date one day later, you'll get
"You cannot edit an event start time to a day different than the one defined in the repeat pattern in this manner. This is not currently supported."

my workaround:

# delete all repeating events for june 08:
DELETE FROM `drupal`.`event` AS `event`,
`drupal`.`node` AS `node`,
`drupal`.`event_repeat_nodes` AS `event_repeat_nodes`
USING `drupal`.`event` AS `event`,
`drupal`.`node` AS `node`,
`drupal`.`event_repeat_nodes` AS `event_repeat_nodes`,
`drupal`.`event_repeat` AS `event_repeat`
WHERE `event`.`nid` = `node`.`nid`
AND `event`.`nid` = `event_repeat_nodes`.`nid`
AND `event_repeat`.`rid` = `event_repeat_nodes`.`rid`
AND `event`.`event_start` < 1214863200
AND `event`.`event_start` > 1212271200

# reset repeat_last_rendered to Jun 1 2008
update event_repeat set repeat_last_rendered="1212271200" where repeat_end > 1213833599;

and downgrade to eventrepeat 5.x-1.0.

Yappyfox’s picture

I am having the same issue, with weekly repeating events..

Here is what I have noted:

My site default time zone is -04:00
My personal TZ is the same.

If I create a weekly event for examples: Every tuesday, 6am - 9am, Events will show up on every tuesday just fine. If I try to create that same event for 6pm - 9pm, the first of the event will be correctly on tues, but every one afterwards will be listed on "Monday"

This seems to be some correlation in the timezoning of the event.

csc4’s picture

I'm seeing the same - TZ GMT +1 (for BST), morning events (with 1.1) create ok and evening events create first one right and subsequent ones one day early.

Reverting to 1.0 allows both morning and afternoon events to be created correctly.

michael_kirk’s picture

Same problem here, however, reverting isn't a solution as the 5.x-1.0 version doesn't support "Every other week".

seanbfuller’s picture

1.0 should support every other week. There wasn't any new functionality added there. Can you double check that?

It sounds like the 1.1 fix to make timezones work correctly (or another patch) is causing this. I'll try to take a look and see if I can find anything.

michael_kirk’s picture

edit: I made a separate issue for this: http://drupal.org/node/269985

confirmed that "every other week" doesnt work with eventrepeat-1.0 using event-1.0

my steps:
I have my own cck type, "course-meeting".

In the admin/content/types/course-meeting
I have configured
Show in event calendar: Only in views for this type

and checked "Allow repeat events"

When I add this content type, I enter the start and finish dates.
september 5 2008-8:00
september 5 2008-11:15

Repeate type: weekly
end settings: december, 5 2008
advanced:
interval: 2
days: Friday

This only produces the original node, and none later in the sequence.
When I change interval to "1" it creates one every week (as it should).

can I give you any more information?

seanbfuller’s picture

Ok, you might be right. I think there was a bug in that version. I thought you meant it wasn't an option. Either way, needs fixing.

ambereyes’s picture

I believe that I found the bug. It is does not seem to have anything to do with timezones, just using the wrong variable for the start date.

Line 1829 of eventrepeat in the _eventrepeat_render_nodes function.

        $date = event_explode_date($repeat_data->event['start']);

should be

        $date = event_explode_date($repeat_data->event_start);

Katrina
--
www.ambereyes.net

Openlogic’s picture

Katrina -

I wasn't able to find the specific line of code (event_explode_date ...) you referenced in the _eventrepeat_render_nodes() function. We're running version 5.x-1.1 of eventrepeat.

Any help would be appreciated.

Thanks

ambereyes’s picture

Yikes!

I am sorry, I am running 5.x-2.x-dev

sorry about that ...
Katrina

cfung’s picture

I can reproduce the problem mentioned in post #5. I'm using v1.1.

Any progress on a patch or bug fix? Many thanks!

seanbfuller’s picture

Has anyone been able to test the fix katrina posted above?

NewZeal’s picture

I tried it but found no such function (event_explode_date()) in 5.x-2.x-dev so it wasn't a go-er.

shashi_lo’s picture

I found the solution for it kicking back one day short for repeating events, but I'm not sure what it does. Some one will know and explain.

Change this near line 2171:

function _eventrepeat_start_time($tracker, $starthour, $startminute, $timezone) {
  $startyear = (int) gmdate("Y", $tracker);
  $startmonth = (int) gmdate("n", $tracker);
  $startday = (int) gmdate("j", $tracker);
  $timezone = $timezone/36;
  $timezone_compare = $starthour*100;
  if ($timezone < 0 && abs($timezone) > ($timezone_compare)) {
    $startday += 1;
  }
  elseif ($timezone > 0 && ($timezone_compare - $timezone) >= 1200) {
    $startday -= 1;
  }
  return gmmktime($starthour, $startminute, 0, $startmonth, $startday, $startyear);
}

To this:

function _eventrepeat_start_time($tracker, $starthour, $startminute, $timezone) {
  $startyear = (int) gmdate("Y", $tracker);
  $startmonth = (int) gmdate("n", $tracker);
  $startday = (int) gmdate("j", $tracker);
  $timezone = $timezone/36;
  $timezone_compare = $starthour*100;
  if ($timezone < 0 && abs($timezone) > ($timezone_compare)) {
    $startday += 1;
  }
  elseif ($timezone > 0 && ($timezone_compare - $timezone) >= 1200) {
    $startday -= 0;
  }
  return gmmktime($starthour, $startminute, 0, $startmonth, $startday, $startyear);
}

The $startday was being pushed a day short. Every other interval still doesn't work as well.

schwascore’s picture

This fixed my weekly and daily repeat problems. After looking through the code, especially comments by rconstantine, it looks like the day offset when comparing local timezones to GMT is where the error begins. My uneducated guess is that this change makes it that there is no day offset, thereby nullifying the error.

seanbfuller’s picture

Status: Active » Fixed

shashi_lo's fix in #17 for 5.x-1.x has been committed to that dev branch. CVS diff message is here:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/eventrepeat...

ambereyes's fix in #11 for 5.x-2.x has been committed to that dev branch. CVS diff message is here:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/eventrepeat...

If others who were having these problems could please pull down the appropriate dev branch and test, that would be greatly appreciated. Marking this as fixed. If you find a problem related to this, please reopen.

NewZeal’s picture

I applied shashi_lo's fix and it appears to work. No complaints. Thanks shashi_lo.

clymber’s picture

Version: 5.x-1.1 » 5.x-1.x-dev

The latest dev branch 1.x fixed the problem for me.

clymber’s picture

Version: 5.x-1.x-dev » 5.x-1.1

Sorry, my goof. I accidentally altered the version of this bug.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.