Hi,
I have an event which is set up to repeat "Every First Saturday" but it seems to be skipping Feb, March, and November of 2009 and August of 2010.

Strangely this event seemed to be repeating properly until I recently edited it to update some of the body text. My guess is that I've updated Date since saving this event initially and re-saving it changed the way its rrule was saved.

I have no idea how to go about fixing this, so any help would be greatly appreciated. Please let me know if there's any more information I can provide to help figure out this problem.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

FoolsRun’s picture

Upon some observation, it appears to skip months after a month that ends on a Saturday, if that's helpful at all.

FoolsRun’s picture

I just updated to the latest -dev version, re-saved the event and this problem still exists.

KarenS’s picture

Status: Active » Postponed (maintainer needs more info)

I am unable to replicate this problem in the latest code, so if you still see it in the latest -dev, change the version in this issue to reflect that and provide more information about exactly what type of date field you are using and how it is configured. I also need to know what version of PHP you are using.

FoolsRun’s picture

Version: 6.x-2.0-rc6 » 6.x-2.x-dev
FileSize
28.55 KB
117.23 KB
123.51 KB
73.8 KB

Hi, thanks for getting back to me.

The field is a "Date" type field configured as shown in the attached screenshots.
PHP version 5.2.8
MySQL version 5.0.67

FoolsRun’s picture

FileSize
115.85 KB

Here's a screenshot of the "Repeats" page of the event, see how it skips months as described.

KarenS’s picture

I copied your setup exactly and can't replicate any problem, all the dates work out fine for me.

Make sure you update to the latest code again, and re-edit the date so it can re-compute the values with the current code. If you still have problems there is something else in your setup that is not the same as what I'm trying to do to replicate your problem, so I need to know more about your setup, what is the first day of the week and timezone setting for your site, are you using user-timezones, and if so, what is your timezone.

Dave Hirschman’s picture

I'm having a similar problem. My "Repeats" tab on the event node is:
Sun, 04/05/2009 12:00pm
Repeats every month first Sunday until Thu Dec 31 2009
Sun, 05/03/2009 12:00pm
Sun, 07/05/2009 12:00pm
Sun, 08/02/2009 12:00pm
Sun, 09/06/2009 12:00pm
Sun, 10/04/2009 12:00pm
Sun, 11/01/2009 12:00pm
Sun, 12/06/2009 12:00pm
As you can see, the first Sunday of June is missing. That would be June 7.
In Fool's Run's data, which is the first Saturday, Feb 7, March 7, and Nov 7 are missing. It is always a date of 7 that does not appear in the repeats.

My Date module version is: 6.x-2.0-rc6
Default time zone: America/Chicago
User-configurable time zones: disabled.
First day of week: Sunday. But if I change 1st day to Monday the same June 7 date is omitted from the repeats.
PHP Version 5.2.8

KarenS’s picture

The rc6 version is not the latest code, the -dev version is always the latest code.

FoolsRun’s picture

You said "re-edit the date", did you mean the event?

I did all of what you suggested and the first Saturdays of Feb and March are still skipped, along with every "First Saturday" that lands on the 7th after that (I think this might have more to due with the previous month ending on a Saturday than with the number 7, but I don't really know).

Oddly if I create a new event starting on Feb 7th, set to repeat "Every First Saturday", it shows up on Feb 7th, and on March 7th, but skips November 7th (the next time after March that Saturday is the 7th) and all "Saturday the 7ths" after that. I doubt this is helpful, but I found it so I'm reporting it.

My default time-zone is America/New York, user time-zones are disabled, the first day of the week is set to Sunday.

Dave Hirschman’s picture

FileSize
820 bytes

This problem appears to be caused by a PHP bug in the date_modify function. If date_modify is passed the last day of the month and asked to increment to the next Sunday, Monday, etc. and that day happens to be the last day of the month (as well as the 7th of the next month), date_modify does nothing - the date is not modified.

In the Date module, date_repeat subdirectory, date_repeat_calc.inc file, function date_repeat_set_month_day deliberately sets the $date object to the last day of the previous month in order to "catch the first of the month." It then calls date_modify, which fails if it is already on the day of the week that it is being asked to jump to.

My Php version is 5.2.8 on both my desktop XAMPP installation and my 1and1.com web site. I've attached a PHP script that demonstrates the problem. I don't have access to other PHP versions to see what happens.

I'm very new to Drupal, CVS, and open source - this is the first time I've poked around the source code - so I'm not sure what is supposed to happen next.

OK - my uploaded file was mangled. Let's try putting the script inline.


echo "<p>PHP Version = ", phpversion(), "</p>\n";

function test($year, $month, $day, $action)
	{
	$dt = new DateTime();
	date_date_set($dt, $year, $month, $day);
	echo '<tr><td>', $dt->format(DATE_COOKIE), "</td><td>$action</td><td>";
	date_modify($dt, $action);
	$result = (date_format($dt, 'n') == $month) ? "Error - did not go to next week" : "Correct";
	echo $dt->format(DATE_COOKIE), "</td><td>$result</td></tr>\n";
	}
echo "<table border='1'><tr><th>Input Date</th><th>Action</th><th>Output Date</th><th>Result</th></tr>\n";
test(2009, 4, 30, "+1 Sunday");
test(2009, 4, 30, "+1 Thursday");
test(2009, 5, 31, "+1 Sunday");
test(2009, 1, 31, "+1 Saturday");
echo "</table>\n";
Andrew Schulman’s picture

subscribing

FoolsRun’s picture

This is still a problem in the latest -dev versions of Date/Calendar

ericm’s picture

The apparently duplicate threads:
#362926: February is Skipped When Repeat is "Every Month / Last Saturday"
and
#416942: Repeating date not correctly showing
and
#370761: Repeats every first Sunday missed out June 2009
are showing the same issue of repeat problems that seem to be associated with the last day or the 7th day of the month, so all four threads are probably arising from the same PHP bug. The one noted by Dave.Hirschman at comment #10 of this thread, and aasarava here.

I posted a detailed sandbox test with the latest -dev versions and all the database and settings described here, for anyone that wants to replicate and debug. Apparently either date_modify() needs to be hacked around in PHP 5.2.x, or a different function to implement the same result needs to be used.

ericm’s picture

Status: Postponed (maintainer needs more info) » Active

Since I didn't see this bug until fairly recently, I wondered if anything in Date module had changed that might have led to its appearance. I went back to my testbed and installed Date-6.x-2.0-rc5, which I had been running late last year on my production site. On my sandbox site, with PHP 5.2.9, and recent -dev versions of Views and CCK, I still see the same bug (exhaustively detailed here, with Date 6.x-2.x-dev 2009-Apr-13, and the -dev versions of Views and CCK at that time).

My production site was moved to a new server as of 2009-Jan-08, with PHP 5.2.8, Date 6.x-2.0-rc6, and showing the dropped/misplaced repeat dates bug. On the previous server it was under PHP version: 5.2.3. But I suspect that back then I wouldn't have noticed the error in dates several months into the future, so it's possible that PHP 5.2.3 was still problematic.

This is making my site's date/calendar system unusable! I don't want people showing up at wrong dates or missing events.

aasarava has posted a patch here that could fix the skipped months, but not the misplaced dates. couloir007 has a fix here. But that fix didn't help me in a test using "repeat every month, the first Thursday." It still skipped months for which the first Thursday was the 7th day of the month.

KarenS’s picture

Status: Active » Postponed (maintainer needs more info)

I am totally unable to replicate this problem so it is something very specific. I have tried different kinds of date fields, different settings for my site timezone, different settings for the first day of the week. Everything except different versions of PHP (which I have no easy way to try). I'm using PHP 5.2 5. #14 also appears to indicate that this is something specific to the environment you're running under.

Since I can't replicate the problem, I'm not comfortable hacking the code, which works perfectly fine for me.

If someone using PHP 5.2.5 (since that's the one thing I can't easy change in my own setup) can post a very detailed report about how their setup is configured I will try to replicate it. I need to know EVERYTHING -- what your site timezone is, exactly specifically how your date field is configured (an export using Content Copy is best), what your web server timezone is, what your database timezone is, what you set up as the first day of the week, and anything else you can think of to make it possible for me to replicate a setup that has this problem.

KarenS’s picture

Marking #362926: February is Skipped When Repeat is "Every Month / Last Saturday" as a duplicate. This part of the code is the same in the D5 and D6 versions.

KarenS’s picture

KarenS’s picture

KarenS’s picture

Status: Postponed (maintainer needs more info) » Fixed

I finally found a way to replicate the problem and I think I have fixed it. I just committed the changes to -dev for both D5 and D6. The changes are there now in cvs and should be in tomorrows -dev tarballs.

ericm’s picture

Super kewl. I will download a D6 Date -dev tarball late tomorrow and test the new version against all of the problematic repeat rules I've encountered. Thank you Karen!

ericm’s picture

Unfortunately, the latest Date -dev doesn't fix the problem as I encounter it. I have started with an fresh install, in the hope that this will provide everything you need to replicate the problem. I am trying hard to include *everything* but please forgive me if I omit anything you need. Just ask and I'll provide it. I'm using an XAMPP installation on a WinXP PC as my sandbox, although my production sites are CentOS on a proper server, because I see the same problem on both systems and pretty much anyone can install XAMPP locally if they want to reproduce this exactly as I have. The following steps were done between 1 and 3pm localtime (EDT/GMT-4).
____________________________

 1. I installed a fresh Drupal 6.11, on an XAMPP for WIndows 1.7.1 system (running on WinXP). This installation uses PHP 5.2.9, mySQL 5.1.33-community, Apache/2.2.11 (Win32), and has both a local system time (webserver time) and Drupal database (site) time of EDT (GMT-4). The sandbox Drupal site for this test is sandbox.local, which I added within the drupal.local multisite. All subsequently installed modules are in the sites\sandbox.local\modules\contrib_modules directory. (Because my production sites are in a multisite setup, and I'm mimicking that.) Everything hereafter was done with the sandbox.local site. I enabled the core syslog module, and ran cron manually.
 2. I downloaded and installed the latest -dev CCK module (6.x-2.x-dev 2009-Apr-30) [unpacked the download, reloaded the Modules page], and enabled Content, Content Copy, Option Widgets, Text and Number.
 3. I downloaded and installed the latest -dev Views module (6.x-2.x-dev 2009-May-07), and enabled Views and Views UI. (Yes, it's probably irrelevant for this test, but important when I move on to including Calendar, once this repeating date problem is solved.)
 4. I downloaded and installed the latest -dev Date module (6.x-2.x-dev 2009-May-05), and enabled Date API, Date, Date Repeat API, Date Timezone, and Date Popup.
 5. I ran cron manually, and got the reminder to set the timezone name from the Status report.
 6. I set the default timezone (admin/settings/date-time) to America/Toronto (which is EDT, GMT-4), User-configurable time zones: enabled (default), First day of week: Sunday (default). Status report is now all green.
 7. I cleared the site cache (admin/settings/performance) and the Views cache (admin/build/views/tools). I reviewed the Status, Available Updates, and site syslog and everything is green. There have been no problems or errors (other than the report to set timezone).
 8. I created a new content type, "Event, repeating" (type: event_repeating).
 9. I added to it a field (admin/content/node-type/event-repeating/fields), with the label "Date, repeating", the field name "field_datetime_repeating", the field type "Datetime", and the form element "Text Field with Date Pop-up and Repeat Options".
 10. After saving the new field, in the resulting "Date, repeating" setup form, under Global settings, I checked the "required" box, selected "Optional" for the "To Date", and left everything else as the default. I saved the form and everything looks good.
 11. I created a new "Event, repeating" node, with "From date" of "2009-03-05" and time "19:30" ("To date and time" left blank), a repeat "Frequency" of "Every" and "Period" of "Months" with an "Until" of "2011-02-04" (no time set), and under "Advanced" selected "Any" for "Month" and "Day of Month" and "First Thursday" for "Day of Week". I saved the node.
 12. I got a node view listing the repeat dates, showing the "missing repeat dates error" -- the repeats for 2009-05-07, 2010-01-07, and 2010-10-07 are missing, as follows:

Date, repeating: 
Repeats every month on the first Thursday until Fri Feb 04 2011 .
Thu, 2009-03-05 19:30
Thu, 2009-04-02 19:30
Thu, 2009-06-04 19:30
Thu, 2009-07-02 19:30
Thu, 2009-08-06 19:30
Thu, 2009-09-03 19:30
Thu, 2009-10-01 19:30
Thu, 2009-11-05 19:30
Thu, 2009-12-03 19:30
Thu, 2010-02-04 19:30
Thu, 2010-03-04 19:30
Thu, 2010-04-01 19:30
Thu, 2010-05-06 19:30
Thu, 2010-06-03 19:30
Thu, 2010-07-01 19:30
Thu, 2010-08-05 19:30
Thu, 2010-09-02 19:30
Thu, 2010-11-04 19:30
Thu, 2010-12-02 19:30
Thu, 2011-01-06 19:30
Thu, 2011-02-03 19:30

The "delta 0" line for this node from the "content_field_datetime_repeating" table of the database is: field_datetime_repeating_value = 2009-03-06 00:30:00, field_datetime_repeating_value2 = 2009-03-06 00:30:00, and field_datetime_repeating_rrule = RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=1TH;UNTIL=20110204T050000Z;WKST=SU. There are no lines in the table for the missing dates.

Here is the Content Copy export (admin/content/types/export) for this content type:

$content['type']  = array (
  'name' => 'Event, repeating',
  'type' => 'event_repeating',
  'description' => 'A repeating event.',
  'title_label' => 'Title',
  'body_label' => 'Body',
  'min_word_count' => '0',
  'help' => '',
  'node_options' => 
  array (
    'status' => true,
    'promote' => true,
    'sticky' => false,
    'revision' => false,
  ),
  'old_type' => 'event_repeating',
  'orig_type' => '',
  'module' => 'node',
  'custom' => '1',
  'modified' => '1',
  'locked' => '0',
  'comment' => '2',
  'comment_default_mode' => '4',
  'comment_default_order' => '1',
  'comment_default_per_page' => '50',
  'comment_controls' => '3',
  'comment_anonymous' => 0,
  'comment_subject_field' => '1',
  'comment_preview' => '1',
  'comment_form_location' => '0',
);
$content['fields']  = array (
  0 => 
  array (
    'label' => 'Date, repeating',
    'field_name' => 'field_datetime_repeating',
    'type' => 'datetime',
    'widget_type' => 'date_popup_repeat',
    'change' => 'Change basic information',
    'weight' => '1',
    'default_value' => 'blank',
    'default_value2' => 'same',
    'default_value_code' => '',
    'default_value_code2' => '',
    'input_format' => 'Y-m-d H:i:s',
    'input_format_custom' => '',
    'year_range' => '-3:+3',
    'increment' => '1',
    'advanced' => 
    array (
      'label_position' => 'above',
      'text_parts' => 
      array (
        'year' => 0,
        'month' => 0,
        'day' => 0,
        'hour' => 0,
        'minute' => 0,
        'second' => 0,
      ),
    ),
    'label_position' => 'above',
    'text_parts' => 
    array (
    ),
    'description' => '',
    'required' => 1,
    'multiple' => 1,
    'repeat' => 1,
    'todate' => 'optional',
    'granularity' => 
    array (
      'year' => 'year',
      'month' => 'month',
      'day' => 'day',
      'hour' => 'hour',
      'minute' => 'minute',
    ),
    'default_format' => 'medium',
    'tz_handling' => 'site',
    'timezone_db' => 'UTC',
    'repeat_collapsed' => '0',
    'op' => 'Save field settings',
    'module' => 'date',
    'widget_module' => 'date',
    'columns' => 
    array (
      'value' => 
      array (
        'type' => 'datetime',
        'not null' => false,
        'sortable' => true,
        'views' => true,
      ),
      'value2' => 
      array (
        'type' => 'datetime',
        'not null' => false,
        'sortable' => true,
        'views' => false,
      ),
      'rrule' => 
      array (
        'type' => 'text',
        'not null' => false,
        'sortable' => false,
        'views' => false,
      ),
    ),
    'display_settings' => 
    array (
      'label' => 
      array (
        'format' => 'above',
        'exclude' => 0,
      ),
      'teaser' => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
      'full' => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
      4 => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
    ),
  ),
);
$content['extra']  = array (
  'title' => '-5',
  'body_field' => '0',
  'menu' => '-2',
);

  13. To demonstrate the "wrong repeat date error" type, I created another "Event, repeating" node. This one is titled Test2, "From date" is "2008-11-03" and time "19:30" ("To date" is blank), repeat is again "Every" and "Months" with "Until" of "2011-10-14" (no time specified). Under "Advanced" I set "Any" for "Month" and "Day of Month" and "Second Thursday" for "Day of Week". I saved the node.
  14. I got a node view showing the repeats with the "Wrong repeat date error" as follows:

Date, repeating: 
Repeats every month on the second Thursday until Fri Oct 14 2011 .
Mon, 2008-11-03 19:30
Thu, 2008-11-13 19:30
Thu, 2008-12-11 19:30
Thu, 2009-01-08 19:30
Thu, 2009-02-12 19:30
Thu, 2009-03-12 19:30
Thu, 2009-04-09 19:30
Thu, 2009-05-07 19:30
Thu, 2009-06-11 19:30
Thu, 2009-07-09 19:30
Thu, 2009-08-13 19:30
Thu, 2009-09-10 19:30
Thu, 2009-10-08 19:30
Thu, 2009-11-12 19:30
Thu, 2009-12-10 19:30
Thu, 2010-01-07 19:30
Thu, 2010-02-11 19:30
Thu, 2010-03-11 19:30
Thu, 2010-04-08 19:30
Thu, 2010-05-13 19:30
Thu, 2010-06-10 19:30
Thu, 2010-07-08 19:30
Thu, 2010-08-12 19:30
Thu, 2010-09-09 19:30
Thu, 2010-10-07 19:30
Thu, 2010-11-11 19:30
Thu, 2010-12-09 19:30
Thu, 2011-01-13 19:30
Thu, 2011-02-10 19:30
Thu, 2011-03-10 19:30
Thu, 2011-04-07 19:30
Thu, 2011-05-12 19:30
Thu, 2011-06-09 19:30
Thu, 2011-07-07 19:30
Thu, 2011-08-11 19:30
Thu, 2011-09-08 19:30
Thu, 2011-10-13 19:30

It is showing 2009-05-07 instead of 2009-05-14, 2010-01-07 instead of 2010-01-14, 2010-10-07 instead of 2010-10-14, 2011-04-07 instead of 2011-04-14, and 2011-07-07 instead of 2011-07-14.

The "delta 0" line for this node from the "content_field_datetime_repeating" table of the database is: field_datetime_repeating_value = 2008-11-04 00:30:00, field_datetime_repeating_value2 = 2008-11-04 00:30:00, and field_datetime_repeating_rrule = RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=2TH;UNTIL=20111014T040000Z;WKST=SU

 15. I ran update.php (not done after the previous modules installs, because this is a fresh installation), cleared the system and Views caches, and got nothing new added to the syslog. The node views still show the repeat errors.
____________________________

I have tried to be complete in my description, but please let me know if there is anything else I can provide.

Eric

ericm’s picture

Status: Fixed » Active

status change (sorry)

Poieo’s picture

Subscribing

KarenS’s picture

@ericm, I have a setup almost identical to yours, on Windows XP, timezone is America/Chicago (-500) instead of -400, which should be close enough to behave the same. I have version PHP 5.2.5 instead of the version you have.

And on my setup the dates are created correctly.

So we're now down to two possibilities: 1) you don't have exactly the same code I am using, 2) the different PHP versions are creating different results (a PHP bug).

ericm’s picture

@KarenS, I have downloaded an old version of XAMPP, v 1.6.5, which uses PHP 5.2.5 instead of 5.2.9 (also, MySQL 5.0.51 instead of 5.1.33). I will try that version on the same Drupal code + database I used in my test, and see if making new but identical nodes creates a different result. I should have an answer by Monday night.

Dave Hirschman’s picture

There is no bug in the Date module - it is definitely a php bug in the date_modify function. Run this on php 5.2.9 to see it fail (for example, http://lsrfrisco.com/date_modify.php):

<html>
<head><title>date_modify test</title></head>
<body>
<h1>date_modify test</h1>
<?php
echo "<p>PHP Version = ", phpversion(), "<br />";
$dt = new DateTime();
date_date_set($dt, 2009, 5, 31);
echo 'Before date_modify: ', $dt->format('l m/j/y'), "<br />";
$action = "+1 Sunday";
date_modify($dt, $action);
echo "After date_modify ($action): ",  $dt->format('l m/j/y') , "<br />",
	"Should be Sunday 6/7/09</p>";
?>
</body>
</html>

If date_modify (in php 5.2.9) is called to add +n Sunday, Monday, etc. on the last day of the month and that day is also Sunday, Monday, etc. then it adds n-1 weeks instead of n weeks to the date. Since it works in php 5.2.5, the bug was introduced after that release.

In the Date module, date_repeat subdirectory, date_repeat_calc.inc file, function date_repeat_set_month_day deliberately sets the $date object to the last day of the previous month in order to "catch the first of the month." It then calls date_modify, which fails if it is already on the day of the week that it is being asked to jump to.

KarenS’s picture

There are some tricks I can use in PHP5 to get it to work right by setting the date to the '0' day of the month, but that won't work in PHP4 which I still need to support. I need to find a fix that will work in PHP4 and in both the 'good' and 'bad' versions of PHP5. Bugger.

gpk’s picture

If it's any help, I'm pretty sure I only noticed problems with repeating dates after upgrading from 6.x-2.0-rc6 to 6.x-2.0. In both cases running on PHP 5.2.8.

ericm’s picture

re: #28, gpk... I am seeing the problem on my production site, which is still using Date 6.x-2.0-rc6, but is PHP 5.2.8. I noticed it after my production site moved off a server that was using PHP 5.2.3.

ericm’s picture

I ran Dave.Hirschman's test HTML file, re comment #26, using the two XAMPP versions, the old with PHP 5.2.5 and the new with 5.2.9. I got what he reported:
_____________________________________

PHP Version = 5.2.9
Before date_modify: Sunday 05/31/09
After date_modify (+1 Sunday): Sunday 05/31/09
Should be Sunday 6/7/09
_____________________________________

PHP Version = 5.2.5
Before date_modify: Sunday 05/31/09
After date_modify (+1 Sunday): Sunday 06/7/09
Should be Sunday 6/7/09
_____________________________________

I copied over the Drupal root directory from my earlier test (comment #21) to the htdocs of the older version XAMPP, so this is running with the identical Drupal code and also the identical database as that test, except now with PHP 5.2.5 and MySQL 5.0.51. I created new repeating event nodes just as before (using the previously created "Events, repeating" node type), and got correctly repeating event listings. For node Test1a...

Date, repeating: 
Repeats every month on the first Thursday until Fri Feb 04 2011 .
Thu, 2009-03-05 19:30
Thu, 2009-04-02 19:30
Thu, 2009-05-07 19:30
Thu, 2009-06-04 19:30
Thu, 2009-07-02 19:30
Thu, 2009-08-06 19:30
Thu, 2009-09-03 19:30
Thu, 2009-10-01 19:30
Thu, 2009-11-05 19:30
Thu, 2009-12-03 19:30
Thu, 2010-01-07 19:30
Thu, 2010-02-04 19:30
Thu, 2010-03-04 19:30
Thu, 2010-04-01 19:30
Thu, 2010-05-06 19:30
Thu, 2010-06-03 19:30
Thu, 2010-07-01 19:30
Thu, 2010-08-05 19:30
Thu, 2010-09-02 19:30
Thu, 2010-10-07 19:30
Thu, 2010-11-04 19:30
Thu, 2010-12-02 19:30
Thu, 2011-01-06 19:30
Thu, 2011-02-03 19:30

There are no missed months. And checking the database table "content_field_datetime_repeating" for the new node (line with delta 0), field_datetime_repeating_value = 2009-03-06 00:30:00, = RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=1TH;UNTIL=20110204T050000Z;WKST=SU same as before.

And for node Test2a...

Date, repeating: 
Repeats every month on the second Thursday until Fri Oct 14 2011 .
Mon, 2008-11-03 19:30
Thu, 2008-11-13 19:30
Thu, 2008-12-11 19:30
Thu, 2009-01-08 19:30
Thu, 2009-02-12 19:30
Thu, 2009-03-12 19:30
Thu, 2009-04-09 19:30
Thu, 2009-05-14 19:30
Thu, 2009-06-11 19:30
Thu, 2009-07-09 19:30
Thu, 2009-08-13 19:30
Thu, 2009-09-10 19:30
Thu, 2009-10-08 19:30
Thu, 2009-11-12 19:30
Thu, 2009-12-10 19:30
Thu, 2010-01-14 19:30
Thu, 2010-02-11 19:30
Thu, 2010-03-11 19:30
Thu, 2010-04-08 19:30
Thu, 2010-05-13 19:30
Thu, 2010-06-10 19:30
Thu, 2010-07-08 19:30
Thu, 2010-08-12 19:30
Thu, 2010-09-09 19:30
Thu, 2010-10-14 19:30
Thu, 2010-11-11 19:30
Thu, 2010-12-09 19:30
Thu, 2011-01-13 19:30
Thu, 2011-02-10 19:30
Thu, 2011-03-10 19:30
Thu, 2011-04-14 19:30
Thu, 2011-05-12 19:30
Thu, 2011-06-09 19:30
Thu, 2011-07-14 19:30
Thu, 2011-08-11 19:30
Thu, 2011-09-08 19:30
Thu, 2011-10-13 19:30

This time the incorrect repeat date problems are not there.

Well, the good news is that I think we have confirmed that the problem is with a bug in the newer PHP versions.

Andrew Schulman’s picture

Reported upstream: http://bugs.php.net/bug.php?id=48232. Maybe they'll fix it, and then you won't have to work around it?

KarenS’s picture

Ok, now we have to find a way to compute this that works right in all versions. Can the people with the alternate systems to test try a couple things to see which give you the right results in both versions of PHP?

1) Set the date to 2009-06-00 00:00:00 (June 0), then do '+1 Sunday'.

2) Set the date to 2009-05-31 00:00:00, then do 'first Sunday'.

3) Set the date to 2009-06-01 00:00:00, then do 'first Sunday'.

4) Set the date to 2009-06-30 00:00:00, then do '-1 Tuesday'. (The last day of June is a Tuesday)

5) Set the date to 2009-07-01 00:00:00, then do '-1 Tuesday'.

6) Same as #4, using 'last Tuesday'.

7) Same as #5 using 'last Tuesday'.

None of those will work in PHP4, I'll probably have to so some alternate workaround for PHP4, but let's at least figure out what will give us consistent results in PHP 5.2.x.

KarenS’s picture

Another to test (5/31 is a Sunday)

8) Set the date to 2009-05-31 00:00:00, then do 'last Sunday'.

9) Same as above, doing '-1 Sunday'.

ericm’s picture

I used code like:

echo "<p>PHP Version = ", phpversion(), "<br />";
$dt1 = new DateTime('2009-05-30 00:00:00');
date_date_set($dt1, 2009, 6, 0);
echo '1) ', $dt1->format('r'), " --[";
$action = "+1 Sunday";
date_modify($dt1, $action);
echo "$action]--> ", $dt1->format('r') , "<br />";

and got:

PHP Version = 5.2.5
1) Sun, 31 May 2009 00:00:00 -0400 --[+1 Sunday]--> Sun, 07 Jun 2009 00:00:00 -0400
2) Sun, 31 May 2009 00:00:00 -0400 --[first Sunday]--> Sun, 07 Jun 2009 00:00:00 -0400
3) Mon, 01 Jun 2009 00:00:00 -0400 --[first Sunday]--> Sun, 07 Jun 2009 00:00:00 -0400
4) Tue, 30 Jun 2009 00:00:00 -0400 --[-1 Tuesday]--> Tue, 23 Jun 2009 00:00:00 -0400
5) Wed, 01 Jul 2009 00:00:00 -0400 --[-1 Tuesday]--> Tue, 30 Jun 2009 00:00:00 -0400
6) Tue, 30 Jun 2009 00:00:00 -0400 --[last Tuesday]--> Tue, 23 Jun 2009 00:00:00 -0400
7) Wed, 01 Jul 2009 00:00:00 -0400 --[last Tuesday]--> Tue, 30 Jun 2009 00:00:00 -0400
8) Sun, 31 May 2009 00:00:00 -0400 --[last Sunday]--> Sun, 24 May 2009 00:00:00 -0400
9) Sun, 31 May 2009 00:00:00 -0400 --[-1 Sunday]--> Sun, 24 May 2009 00:00:00 -0400

...and...

PHP Version = 5.2.9
1) Sun, 31 May 2009 00:00:00 -0400 --[+1 Sunday]--> Sun, 31 May 2009 00:00:00 -0400
2) Sun, 31 May 2009 00:00:00 -0400 --[first Sunday]--> Sun, 07 Jun 2009 00:00:00 -0400
3) Mon, 01 Jun 2009 00:00:00 -0400 --[first Sunday]--> Sun, 07 Jun 2009 00:00:00 -0400
4) Tue, 30 Jun 2009 00:00:00 -0400 --[-1 Tuesday]--> Tue, 23 Jun 2009 00:00:00 -0400
5) Wed, 01 Jul 2009 00:00:00 -0400 --[-1 Tuesday]--> Tue, 30 Jun 2009 00:00:00 -0400
6) Tue, 30 Jun 2009 00:00:00 -0400 --[last Tuesday]--> Tue, 23 Jun 2009 00:00:00 -0400
7) Wed, 01 Jul 2009 00:00:00 -0400 --[last Tuesday]--> Tue, 30 Jun 2009 00:00:00 -0400
8) Sun, 31 May 2009 00:00:00 -0400 --[last Sunday]--> Sun, 24 May 2009 00:00:00 -0400
9) Sun, 31 May 2009 00:00:00 -0400 --[-1 Sunday]--> Sun, 24 May 2009 00:00:00 -0400
KarenS’s picture

OK, one more test if you don't mind. Can you test 'second Sunday' vs '+2 Sunday'?

It looks like 'first' works correctly for +1 and all the other values work right either way, so the simplest fix would be to just substitute '+1' with 'first' in PHP 5.2+ and leave everything else alone. If 'second' does not have the same problems, I can do that, otherwise I may need to use the english text in all cases ('second' instead of +2) except in PHP5 where I have to leave things the way they work now, because the current method is the only one that will work there.

ericm’s picture

Here they are (all starting with date set to 2009-05-31 00:00:00):

PHP Version = 5.2.5
10) Sun, 31 May 2009 00:00:00 -0400 --[+1 Sunday]--> Sun, 07 Jun 2009 00:00:00 -0400
2) Sun, 31 May 2009 00:00:00 -0400 --[first Sunday]--> Sun, 07 Jun 2009 00:00:00 -0400
11) Sun, 31 May 2009 00:00:00 -0400 --[+2 Sunday]--> Sun, 14 Jun 2009 00:00:00 -0400
12) Sun, 31 May 2009 00:00:00 -0400 --[second Sunday]--> Sun, 14 Jun 2009 00:00:00 -0400

and

PHP Version = 5.2.9
10) Sun, 31 May 2009 00:00:00 -0400 --[+1 Sunday]--> Sun, 31 May 2009 00:00:00 -0400
2) Sun, 31 May 2009 00:00:00 -0400 --[first Sunday]--> Sun, 07 Jun 2009 00:00:00 -0400
11) Sun, 31 May 2009 00:00:00 -0400 --[+2 Sunday]--> Sun, 07 Jun 2009 00:00:00 -0400
12) Sun, 31 May 2009 00:00:00 -0400 --[second Sunday]--> Sun, 14 Jun 2009 00:00:00 -0400

#2 here is the same as #2 in my earlier test (comment #34). Also, I tried this set of four with the date set to 2009-06-00 and it looked identical.

KarenS’s picture

Then I have to use 'first', 'second' etc in PHP5 to get the right results. There are still other places in the code that are going to be broken by this bug tho, places where we have a date and need to move it forward or backward by some number of weeks. All of them will be broken by this. Sigh. Ok, working on a fix for this one. Thanks for all the help.

gpk’s picture

Thanks for all your work on this Karen, it's hugely appreciated.

KarenS’s picture

Status: Active » Needs review

I've committed some changes to use 'First Sunday' instead of '+1 Sunday', they need to be tested in various environments, including PHP4. That should fix things like 'First Sunday' of every month or every year. There will be other places this will be a problem, but it's at least a start.

I just made the commits so they are not in the tarball yet. You'll have to wait until the tarball is updated or get them directly from cvs.

FoolsRun’s picture

I just tested the May 12th -dev release and it's solved my initial "Every First Saturday" problem!

Thanks for all your hard work on this and other modules!

gpk’s picture

Status: Needs review » Needs work

I've just updated to the latest dev tarball (and I've checked that it includes changes shown in http://drupal.org/cvs?commit=210240) but #416942: Repeating date not correctly showing does not appear to have been corrected by this fix. Should it have been? The problem over there occurs with daily repeats that miss out certain days of the week.

Thanks,

KarenS’s picture

I fixed the 'every month' and 'every year' because those can be fixed by using 'first', 'second', etc. Every day is a tougher nut to crack because 'first' isn't a solution. I have no idea what to do about that one.

If anyone wants to try to find a fix, first provide an example of a rule that doesn't work so others can try it out and then test some methods of incrementing the days that will work in all PHP versions.

ericm’s picture

Status: Needs work » Needs review

I just tested the latest -dev (2008-05-13, which includes "#369020 Switch '+1 Sunday' to 'First Sunday' to over PHP5 bug.") under PHP 5.2.9 and it creates perfect repeat dates for all the problematic events I've been struggling with. They are all monthly repeats, so I'm a relatively easy case. But ... it works!

I'll keep my sandbox setup in place, just in case Karen comes up with any solution that she likes better and it needs testing. Thank you Karen!

gpk’s picture

@42: I was bit imprecise in my description above (#41) "The problem over there occurs with daily repeats that miss out certain days of the week".

What I should have said was "events that repeat on every Xxx-day" (in my case I have an event that repeats on all days Mon - Sat so I positively select 6 of those every Xxx-day items in the dropdown).

Currently it is the first Xxx-day of the month that is missing - after the first weekend the repeats show just fine - and that seems to be the same as the problem fixed above so I wonder if it's just a matter of applying the same technique in the relevant place in the code (wherever that is!) so that the first Xxx-day is shown in the repeats as well as the 2nd, 3rd... However I may be off track since I'm merely guessing that the calculations currently work by finding the first Xxx-day and then moving on to the 2nd, 3rd, ...

Joel MMCC’s picture

The PHP bug is not in date_modify() (actually DateTime::modify — date_modify() is an alias of that), but in strtotime() (DateTime::modify basically applies strtotime to the original date).

Also, the bug is not introduced in later versions (PHP 5.2.8+). It was fixed then. The behavior that led to this bug was in fact the correct behavior, and the code in KarenS’s was module was incorrect, but its incorrectness was obscured by the PHP bug in the 5.2.5 that she was using.

The underlying problem is due to misinterpretation of the GNU Date syntax. In a nutshell, “+2 Monday” is not a synonym for “second Monday,” nor is it intended to be!

Saying “second Monday” means you want the 2nd Monday of the month, as expected. “+2 Monday” means that you want to advance two Mondays from (not necessarily after!) the starting date! If the starting date is itself a Monday, that counts as the first advanced date, so you only advance to the following Monday with “+2 Monday”! This is by design and matches the GNU spec, but was incorrectly implemented in PHP 5.2.6 (maybe 5.2.7) and earlier.

Karen, apparently you wrote and tested this module under 5.2.5, and due to that glitch, you assumed that “+2 Monday” was synonymous with “second Monday” and of course would be easier to implement (numbers being easier to program than words). Due to the PHP bug, this passed all the tests you gave it, so you had no reason to question that assumption of the synonym. But that assumption was in fact incorrect all along. Spelling out the ordinal is the only valid way to do this, and was all along.

arlinsandbulte’s picture

Thanks for the clarifications, Joel! I hope that helps Karen out a bunch. At least we have a better idea of the problem. Maybe a workaround for everyone can be implemented.

Unfortunately, my host is on PHP 5.2.6 right now. I will need to try to get them to upgrade....

KarenS’s picture

You are misinterpreting what I have done and what the bug is. If you set the date to 5/31 (a Sunday) and then do date_modify("+1 Sunday"), IT DOES NOT MOVE. That is a bug. I never said or thought that +1 Sunday means 'First Sunday'. All my code does things like move to the last day of the previous month and then do +1 Sunday, which should take me to the first Sunday in the month. There is no possible way that not moving off of the 31st of the previous month if it happens to be a Sunday is the correct behavior.

On top of that, I had to find a way to do this that would work in my PHP4 code, which uses the old PEAR date code to move backwards and forwards a week at a time, so doing +1/-1 should work correctly in both if you do what I have done, which is to reset to a date outside the current month and then move. I could not use the ordinal 'first' or 'second' because that won't work in the code that I am trying to maintain to provide comparable functionality in versions below PHP 5.2.

If you read through the code comments you would have seen where I say exactly what I'm trying to do and why, and if you read through the PHP4 module wrapper code you would see that I have stated that we can implement only a modified part of the PHP5.2 functionality to limit it to things I can replicate in PHP4.

I have spent hundreds and hundreds of hours on this project. It takes up all my free time, and never leaves my mind. I feel personally responsible for making this code work correctly for the thousands of people using it. I don't think I deserve to be chewed out in bold type by someone who makes incorrect assumptions about whether I know what I am doing.

KarenS’s picture

Dang, I hate being wrong. I checked out the GNU spec and it *does* say that +1 will advance only if necessary. I think that's bizarre, but that's the standard.

But I also see can use 'next' and 'last' to get what I want in PHP5, which is how we can fix the remaining problem of navigating days. I'll have to do with them what I did with 'first' and 'second', which is to swap those out in the PHP4 code and use the '+1' and '-1' that will work there.

So, sorry for the rant. I think it was the comment about assuming I was doing it because I thought '+1' meant 'first' and that I did it because it was 'easier'. NOTHING about this project is easy, and maintaining a functional PHP4 equivalent is a huge amount of work that requires all kinds of compromises.

Joel MMCC’s picture

I wasn’t chewing you out. I was simply using boldface as strong emphasis, as intended, to call attention to the parts that I thought were most important. If I intended to chew anyone out, it would be in UPPERCASE. Maybe in underscored boldfaced italics, all in H1 size.

You have created several wonderful modules that work together to make the whole greater than the sum of the parts, and I for one deeply appreciate all that you do.

Since I rarely chew anyone out on the Internet, and certainly not someone devoting much time, energy, and talent to a project such as this, the only time you’ll see uppercase from me is in the occasional Audibly Condensed but Rarely Obscure Nomenclature of Your Meaning of some word or phrase: in other words, an A.C.R.O.N.Y.M. ;-) (Or maybe keywords in a code excerpt.)

I apologize for the misinterpretation of your thought processes in writing this.

gpk’s picture

@48: In view of the angst you are going through on account of *my* problem not being fixed yet, time to say another huge thanks for all your work on this and the project as a whole. I suspect that I am one of many who, compared with you, do little more than tinker round the edges with Drupal and and are utterly in awe of your brilliance, commitment, good humor, patience, generosity, skill and expertise and appreciate that we depend on you more than is perhaps healthy! Please don't feel any burden of responsibility, just our huge appreciation for your gift.

So for now I'll just say - thank you!

[edit] Ah - I've only now caught up with the full texts of the comments above, but that doesn't change anything I've said above nor the huge debt of gratitude the community project I'm working on owes you. I just hope we can do Calendar/Date justice by our implementation.

Joel MMCC’s picture

Also, don’t feel too badly about being confused by that confusing GNU spec. It confused the PHP people, too, all the way through version 5.2.6, which is the real reason that this issue exists in the first place. You’re having to work around their confusion, not just your own.

And you’re absolutely right: the GNU spec is bizarre. I can’t think of any real-world scenario in which their spec for “±n DayOfWeek” would actually be useful, and it is certainly counter-intuitive (the whole point of that spec was to provide a way to translate plain, intuitive casual English date phrases like “next Friday” into calculated dates).

Andrew Schulman’s picture

And you’re absolutely right: the GNU spec is bizarre. I can’t think of any real-world scenario in which their spec for “±n DayOfWeek” would actually be useful,

[rant]
No indeed, it reads to me like a recipe for forcing people to write special case code every time they want to use date_modify(). If today is Sunday and I say "next Sunday" or "+1 Sunday", I don't mean today.

So what does +0 Sunday mean? The same as +1 Sunday? That's messed up.
[/rant]

swellbow’s picture

I am not trying to hijack an existing issue, and will post separately if needed. I think my issue is related. I updated to the latest -dev (2009-Jun-21), ran updates, cleared cache. This issue happens before dealing with Views.

I am encountering similar "holes in my data" when choosing to repeat a date every Tuesday, Wednesday, Thursday, Friday, and Saturday. An example, creating an item starting at 1:00PM MDT today, repeating as described (Tues - Sat) until 2012, starts off thus:

Fri, 06/26/2009 - 1:00pm
Sat, 06/27/2009 - 1:00pm
Tue, 06/30/2009 - 1:00pm
Tue, 07/07/2009 - 1:00pm
Wed, 07/08/2009 - 1:00pm
Thu, 07/09/2009 - 1:00pm
...

The first week of the month is skipped. Looking further into the data, the repeat stops at the end of the month, picking up again on the next available Tuesday:

2009-06-27T19:00:00 Saturday
2009-06-30T19:00:00 Tuesday
2009-07-07T19:00:00 Tuesday
...(leaving out correct middle of the month dates)
2009-07-30T19:00:00 Thursday
2009-07-31T19:00:00 Friday
2009-08-04T19:00:00 Tuesday
...
2009-08-28T19:00:00 Friday
2009-08-29T19:00:00 Saturday
2009-09-01T19:00:00 Tuesday
...
2009-09-29T19:00:00 Tuesday
2009-09-30T19:00:00 Wednesday
2009-10-06T19:00:00 Tuesday

Note that the August to September transition is OK since the month ends at the end of the rule.

This module is amazing and I am more than happy to be using it. Let me know if you need any more information or if I need to place this in a separate issue. Thanks!

gpk’s picture

@53: sounds like the same issue. Indeed, the problem rears its head before Views gets involved - though it's often in a Calendar View that one one notices it first.

Since the problem with the "Every first xxx-day" rule has been fixed you may find that a workaround is to use Every first Tuesday as well as Every Tuesday (sim. for Weds etc). If this gives you a duplicate repeat on Tuesday 1 September then try Every first Tuesday, Every second Tuesday, Every third Tuesday, Every fourth Tuesday and Every Fifth Tuesday, with a rinse-and-repeat for other days of the week.

To fix the outstanding problem some further changes to the code based on the approach in http://drupal.org/cvs?commit=210240 are probably needed so that the "Every xxx-day" rule correctly finds the First xxx-day, which that commit fixed (see #41 - #44). Unfortunately no one (myself included) seems to have had the time to look into this in detail.

swellbow’s picture

@54 Thanks gpk, this is a perfect workaround (tested and works).

I guess the easiest way to fix this one would be to remove the options for "every xxxday" since the remaining options ("every first xxxday - every fifth xxxday") can take care of those scenarios. True, it's a few more clicks, but if it simplifies things...

I looked at the diffs from those commits and basically have no idea where to start trying to patch this. I'll use the workaround for now! Thanks!

ampersat’s picture

This inconsistency seems closely related, but if it needs to be a new bug, let me know and I'll create a new issue.

An event that repeats every week seems to work very differently than every day (or every month). If I set an event to every first Saturday with a repeat of every day or every month, it shows on the first Saturday of every month. However, if I set it to repeat every week, it shows up every Saturday.

Also, if I have an event that repeats every Saturday and I set it to every day, every week, or every month, it shows up on every Saturday. However, if I change the event to repeat every Saturday and every Tuesday (any two or more days will work) and set it to repeat every day or month, the first week is skipped unless it starts on the day designated by the site configuration as the first day of the week. The first week is not skipped if I set it to repeat every week.

So, in the "every first Saturday" case, a repeat of every week generates unexpected results, while "every Saturday and every Tuesday" case, a repeat of every week is correct while everyone else is wrong, but only if more than one weekday is specified.

arlinsandbulte’s picture

@Karen: where does this issue now stand?
In your last comment in #48, you recognize some errors... has that been corrected?

FWIW: I agree the the PHP4 support is a HUGE pain and I would wholeheartedly support dropping its support...

gpk’s picture

@56: I think you've hit both this issue and another one...

The "other" (new) one being more of a usability issue re. what happens if you select the repeat to be Every week and then in the Advanced fieldset go for Every first Saturday. I wonder if it would make more sense for an Advanced setting to more completely override a simple Every week repeat?? Having said that it doesn't really make sense to me to specify Every week in conjunction with Every first Saturday. Every month/Every first Saturday would be a bit more logical I think? So perhaps this is actually a (tricky) UI issue. This discussion as you suggest probably belongs in a new issue.

However your second point is very interesting. I can also get "missed" days if I set an event to repeat Every Monday - Saturday. I had been thinking of this in terms of "repeat Every day and use the Advanced option to specify which days" and yes this causes Tues 1 to Sat 5 Sep to be missed out. However by setting the repeat to Every week all is well! (Again, as you say, using the Every month option in conjunction with Every Monday - Saturday causes the same problem, but to me this makes little sense as a combination.)

So (@57 and anyone else who is following along), to ensure that Every Xxx-day repeats always work properly, just make sure to select Every week in the basic Repeat options.

I had been assuming the missing days were caused by a bug in the date calculating code related to the First Xxx-day problem this issue was originally about, but maybe it is as much to do with the UI allowing mutually incompatible options to be selected?? (i.e. combinations of options that the code was never designed or intended to cope with.) On the other hand maybe all those ways of setting up the repeat should work ... what seems to happen though (for example) is that when the change of month happens between a Monday and a Saturday (which bound the range of days I have selected for repeats) then the calculation gets confused ... Sorry KarenS et al, not my most well-thought-out bit of prose here!

Owen Barton’s picture

FileSize
658 bytes
1.8 KB

I was getting the following simpletest fail on my (shiny new) Ubuntu 9.10 build, using the default PHP 5.2.10-2ubuntu6.3 on both 2.x dev and latest stable releases.

RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO; Starting 1997-09-22 09:00:00; results: 1997-09-22 09:00:00, 1997-09-29 09:00:00, 1997-10-27 09:00:00, 1997-11-24 09:00:00, 1997-12-29 09:00:00, 1998-01-26 09:00:00	Other	date_repeat.test	171	DateRepeatTestCase->testDateRepeat()

i.e. we should get:
1997-09-22 09:00:00, 1997-10-20 09:00:00, 1997-11-17 09:00:00, 1997-12-22 09:00:00, 1998-01-19 09:00:00, 1998-02-16 09:00:00
- but instead get:
1997-09-22 09:00:00, 1997-09-29 09:00:00, 1997-10-27 09:00:00, 1997-11-24 09:00:00, 1997-12-29 09:00:00, 1998-01-26 09:00:00

Having carefully read this issue a couple of times, it appears that date_repeat added code to work around a PHP bug. It looks like this bug was subsequently fixed upstream (one is linked above, although http://bugs.php.net/bug.php?id=43452 appears to perhaps be the actual code change).

My guess is that the upstream fix to PHP broke the workaround, because when I remove the workaround (the chunk at http://drupalcode.org/viewvc/drupal/contributions/modules/date/date_repe... and attached patch) the issue no longer occurs and tests pass. A quick drush script to test this one thing is attached also.

I don't think the patch as is is committable, because it would break older PHP versions. However, Ubuntu 9.10 is likely to be pretty popular soon, so it seems like it would be good to address this issue (or have people show up at events on the wrong day!). KarenS or other date maintainers - what is your preferred way to handle multiple PHP versions for this kind of thing?

Owen Barton’s picture

Status: Needs review » Needs work

Nothing is ever easy, of course - on running the full tests I noticed that reverting the above causes a different test to fail:

RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR; Starting 1997-09-05 09:00:00; results: 1997-09-05 09:00:00, 1997-10-03 09:00:00, 1997-12-05 09:00:00	Other	date_repeat.test	146	DateRepeatTestCase->testDateRepeat()
KarenS’s picture

Blech! Yeah I know about this one and am not really sure of the best way to go. I'm open for ideas that will fix things for everyone. If we can find something that breaks PHP 4 but works for everything else, I'm willing to consider it. I'm almost ready to wash my hands of all the PHP 4 problems once and for all.

Joel MMCC’s picture

I for one certainly wouldn’t blame you for that. Even the PHP people no longer support PHP4.

It’s dead, Ji — er, Karen!! :-)

Gribnif’s picture

FileSize
944 bytes

In #56, @bounsy wrote:

Also, if I have an event that repeats every Saturday and I set it to every day, every week, or every month, it shows up on every Saturday. However, if I change the event to repeat every Saturday and every Tuesday (any two or more days will work) and set it to repeat every day or month, the first week is skipped unless it starts on the day designated by the site configuration as the first day of the week. The first week is not skipped if I set it to repeat every week.

I also hit this same problem. The reason seems to be that the RRULE generated by the view is using a frequency of DAILY, which the current code changes to MONTHLY. This fails when the list of weekdays (BYDAY) spans two months.

Attached is a patch which changes this to WEEKLY. I re-ran it against the simpletests, and no new ones fail (there was one failure even before my change.)

Since this is probably a different issue from the one addressed in this topic, I have created #706006: Dates that repeat on certain days of the week don't always work.

primerg’s picture

I wrote my findings on this issue here http://drupal.org/node/694728 explaining the problem and solution. Someone noted that it was somehow a duplicate issue so I am posting the link here. I did not create a patch nor run a simpletests so if anyone is willing to do that, please post your results.

Alexander Ufimtsev’s picture

I came across similar problem in 5.x-2.8 code as in #63. I was able to reproduce this problem with the latest 6.x-2.x-dev code as well on PHP 5.2.10 and PHP 5.3.2.

To reproduce: set up an event that repeats from 25 May until 7th of June 2010 and specify to repeat every mon, tue, wed, thu, and fri.
Events on 1,2,3 and 4th of June are not going to appear, while 7th of June appears fine.

The problem line is with logic that calls date_modify (line 288 in 6.x-2.x-dev code)

            // If we're already on the right day, don't jump or we
            // will prematurely move into the next week.
            if (date_format($current_day, 'l') != $day) {
              date_modify($current_day, '+1 '. $day);
              $moved = TRUE;
            }

When first period (May) is over, current day is set to 1st of June, which is Tue. Once date_modify executes, it moves current day to June 7th. However, correct behaviour is not to move the day at all at the start of the period.

The only solution I found atm is to use code in #706006: Dates that repeat on certain days of the week don't always work, which proposes to change default period from 'MONTHLY' to 'WEEKLY'.. (thanks Gribnif).

Many thanks,
Alexander

arlinsandbulte’s picture

Status: Needs work » Fixed

Now that #706006: Dates that repeat on certain days of the week don't always work is applied, I could not reproduce the problem as explained in #65 above.
So, I am going to mark this as fixed, assuming the problem was fixed in that issue.

That assumption might be totally wrong, though. #59 & #60 might still be valid.

I think this issue has grown to be quite long and confusing, so PLEASE DON'T REOPEN this issue if you find you have a similar problem.
Instead, open a new issue with clear directions on how to reproduce your bug and reference this issue there.
Thanks.

Status: Fixed » Closed (fixed)

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

baff’s picture

FileSize
64.13 KB
60.8 KB

ignor this