From: Jim Hu <ji...@ta...> - 2005-12-02 17:47:25
|
From the bbs: http://phpicalendar.net/forums/viewtopic.php?p=1395#1395 Dates specified as repeating on the last Wed of the month don't calculate properly. They disappear when a short month follows a long month. From what I can figure out, it turns out that this is because of the way we calculate $next_range_time for that kind of event. ical_parser.php calls date(t) to get the last day of the current month and uses that to calculate where the days are in the last week. It then passes the last day of the month on as $next_range_time and when the loop increments by $interval (a month in this case), you wind up jumping from Jan 31 to Feb 31, which gets converted to March 3 (unless it's a leap year). The byday subroutine then correctly grabs just the month and calculates the last wednesday in March correctly, having skipped February altogether. I believe that the solution is to just reset $next_range_time to the start of the current month inside the code that deals with byday events. #reset next_range_time to start of month $next_range_time = strtotime(date('Y-m-'.'1', $next_range_time)); This works in my test install and I put it in CVS. However, I'm not sure if it's in the right place in terms of the nesting of the loop. Could this bug show up for other kinds of byday events? Also, this is in the code case 'MONTHLY': if (empty($bymonth)) $bymonth = array(1,2,3,4,5,6,7,8,9,10,11,12); $next_range_time = strtotime(date('Y-m-01', $next_range_time)); $next_date_time = $next_date_time; The last two lines in that block don't do anything...they set vars to their current values, don't they? The last line has to be useless. Does the other one set $next_range_time if it starts out undef? Or is it just vestigial? ===================================== Jim Hu Associate Professor and Associate Head for Graduate Programs Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054 |