Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix 1 For recurrtype 2 recurring appointments ("Last Saturday", "3rd Monday") set on the 29th, 30th or 31st of a particular month, and subsequently reopened for editing on this date or subsequent dates in the recurring sequence that are the 29th, 30th or 31st of a month, the "Last (weekday name)" option will not be shown (even though it is set), the default "day" option shows. If the appointment is re-saved (with "All" selected) without re-selecting the option, it will be over written by default "day" option. The problem is related to how the option list is put together. Initially on the server side all recurrtype 1 (rt1) options and all possible recurrtype 2 (rt2) options (including one that may not be required) are output to HTML with the appropriate option set to selected (lines 1416-1422). Then on the client side the index of the set option is recorded in a variable (si) and all rt2 options are removed (line 1023) then one or more (required) options are written back. Next selectedIndex needs to be reset. This is where the problem is. The index for the set option ("Last weekday") for rt2 appoinments (29th, 30th or 31st) is not being reset. For all other possible appointments it is (line 1026). So a new line of code is needed to do this.... else f.form_repeat_type.selectedIndex = 5; Since for these appointments the set option is written back to a new position (client side) the index on the client side (5 (<> si)) is required. Fix 2 When recurring appointments are selected in the "Add New Event" window in a timezone with a positive UTC offset, for a date selected that is the 4th occurrence of a particular weekday that has a 5th occurrence that is the last day of the month, the "Last (weekday name)" option will appear in addition to the "4th (weekday name)" option making it possible to set an appointment not corresponding to the selected appointment date. Line 1016 controls whether "Last weekday" option will appear for a particular date... if (tmp.getUTCDate() - d.getUTCDate() < 7) { The term tmp.getUTCDate() should be be giving the number of days in the month but for time zones with positive UTC offsets it is incorrect, it returns a value that is short by one. The date object (tmp) was created with... var tmp = new Date(d.getUTCFullYear(), d.getUTCMonth() + 1, 0); The date is input with format (year, month, day) which the Date function interprets as local, resulting in a date object that contains a zero time component (00:00:00). Consequently for positive UTC offset time zones when getUTCDate() is applied the date for the previous day is returned (relative to local time zone), which is the days of the month minus one. (The term d.getUTCDate() gives the correct date, date object d is created with... var d = new Date(f.form_date.value); Here f.form_date.value contains date in format "YYYY-MM-DD" which the Date function interprets as UTC, so for positive UTC offsets date object contains time component equal to the offset. Applying getUTCDate() returns the local date).
- Loading branch information