Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#68 | k1.jpg | 60.8 KB | baff |
#68 | k2.jpg | 64.13 KB | baff |
#63 | date_repeat_freq.patch | 944 bytes | Gribnif |
#59 | 369020.patch | 1.8 KB | Owen Barton |
#59 | qtest.php_.txt | 658 bytes | Owen Barton |
Comments
Comment #1
FoolsRun CreditAttribution: FoolsRun commentedUpon some observation, it appears to skip months after a month that ends on a Saturday, if that's helpful at all.
Comment #2
FoolsRun CreditAttribution: FoolsRun commentedI just updated to the latest -dev version, re-saved the event and this problem still exists.
Comment #3
KarenS CreditAttribution: KarenS commentedI 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.
Comment #4
FoolsRun CreditAttribution: FoolsRun commentedHi, 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
Comment #5
FoolsRun CreditAttribution: FoolsRun commentedHere's a screenshot of the "Repeats" page of the event, see how it skips months as described.
Comment #6
KarenS CreditAttribution: KarenS commentedI 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.
Comment #7
Dave Hirschman CreditAttribution: Dave Hirschman commentedI'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
Comment #8
KarenS CreditAttribution: KarenS commentedThe rc6 version is not the latest code, the -dev version is always the latest code.
Comment #9
FoolsRun CreditAttribution: FoolsRun commentedYou 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.
Comment #10
Dave Hirschman CreditAttribution: Dave Hirschman commentedThis 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.
Comment #11
Andrew Schulman CreditAttribution: Andrew Schulman commentedsubscribing
Comment #12
FoolsRun CreditAttribution: FoolsRun commentedThis is still a problem in the latest -dev versions of Date/Calendar
Comment #13
ericm CreditAttribution: ericm commentedThe 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.
Comment #14
ericm CreditAttribution: ericm commentedSince 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.
Comment #15
KarenS CreditAttribution: KarenS commentedI 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.
Comment #16
KarenS CreditAttribution: KarenS commentedMarking #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.
Comment #17
KarenS CreditAttribution: KarenS commentedMarking #416942: Repeating date not correctly showing as a duplicate.
Comment #18
KarenS CreditAttribution: KarenS commentedMarked #370761: Repeats every first Sunday missed out June 2009 as a duplicate.
Comment #19
KarenS CreditAttribution: KarenS commentedI 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.
Comment #20
ericm CreditAttribution: ericm commentedSuper 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!
Comment #21
ericm CreditAttribution: ericm commentedUnfortunately, 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:
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:
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:
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
Comment #22
ericm CreditAttribution: ericm commentedstatus change (sorry)
Comment #23
Poieo CreditAttribution: Poieo commentedSubscribing
Comment #24
KarenS CreditAttribution: KarenS commented@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).
Comment #25
ericm CreditAttribution: ericm commented@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.
Comment #26
Dave Hirschman CreditAttribution: Dave Hirschman commentedThere 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):
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.
Comment #27
KarenS CreditAttribution: KarenS commentedThere 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.
Comment #28
gpk CreditAttribution: gpk commentedIf 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.
Comment #29
ericm CreditAttribution: ericm commentedre: #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.
Comment #30
ericm CreditAttribution: ericm commentedI 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...
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...
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.
Comment #31
Andrew Schulman CreditAttribution: Andrew Schulman commentedReported upstream: http://bugs.php.net/bug.php?id=48232. Maybe they'll fix it, and then you won't have to work around it?
Comment #32
KarenS CreditAttribution: KarenS commentedOk, 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.
Comment #33
KarenS CreditAttribution: KarenS commentedAnother 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'.
Comment #34
ericm CreditAttribution: ericm commentedI used code like:
and got:
...and...
Comment #35
KarenS CreditAttribution: KarenS commentedOK, 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.
Comment #36
ericm CreditAttribution: ericm commentedHere they are (all starting with date set to 2009-05-31 00:00:00):
and
#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.
Comment #37
KarenS CreditAttribution: KarenS commentedThen 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.
Comment #38
gpk CreditAttribution: gpk commentedThanks for all your work on this Karen, it's hugely appreciated.
Comment #39
KarenS CreditAttribution: KarenS commentedI'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.
Comment #40
FoolsRun CreditAttribution: FoolsRun commentedI 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!
Comment #41
gpk CreditAttribution: gpk commentedI'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,
Comment #42
KarenS CreditAttribution: KarenS commentedI 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.
Comment #43
ericm CreditAttribution: ericm commentedI 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!
Comment #44
gpk CreditAttribution: gpk commented@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, ...
Comment #45
Joel MMCC CreditAttribution: Joel MMCC commentedThe 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.
Comment #46
arlinsandbulte CreditAttribution: arlinsandbulte commentedThanks 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....
Comment #47
KarenS CreditAttribution: KarenS commentedYou 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.
Comment #48
KarenS CreditAttribution: KarenS commentedDang, 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.
Comment #49
Joel MMCC CreditAttribution: Joel MMCC commentedI 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.
Comment #50
gpk CreditAttribution: gpk commented@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.
Comment #51
Joel MMCC CreditAttribution: Joel MMCC commentedAlso, 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).
Comment #52
Andrew Schulman CreditAttribution: Andrew Schulman commented[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]
Comment #53
swellbow CreditAttribution: swellbow commentedI 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:
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:
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!
Comment #54
gpk CreditAttribution: gpk commented@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.
Comment #55
swellbow CreditAttribution: swellbow commented@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!
Comment #56
ampersat CreditAttribution: ampersat commentedThis 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.
Comment #57
arlinsandbulte CreditAttribution: arlinsandbulte commented@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...
Comment #58
gpk CreditAttribution: gpk commented@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!
Comment #59
Owen Barton CreditAttribution: Owen Barton commentedI 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.
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?
Comment #60
Owen Barton CreditAttribution: Owen Barton commentedNothing is ever easy, of course - on running the full tests I noticed that reverting the above causes a different test to fail:
Comment #61
KarenS CreditAttribution: KarenS commentedBlech! 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.
Comment #62
Joel MMCC CreditAttribution: Joel MMCC commentedI for one certainly wouldn’t blame you for that. Even the PHP people no longer support PHP4.
It’s dead, Ji — er, Karen!! :-)
Comment #63
Gribnif CreditAttribution: Gribnif commentedIn #56, @bounsy wrote:
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.
Comment #64
primerg CreditAttribution: primerg commentedI 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.
Comment #65
Alexander Ufimtsev CreditAttribution: Alexander Ufimtsev commentedI 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)
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
Comment #66
arlinsandbulte CreditAttribution: arlinsandbulte commentedNow 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.
Comment #68
baff CreditAttribution: baff commentedignor this