Open
Bug 160821
Opened 23 years ago
Updated 2 years ago
Handling of yearly recurring events that start on February 29th (Leap Year) is unclear
Categories
(Calendar :: General, defect)
Calendar
General
Tracking
(Not tracked)
NEW
People
(Reporter: brant, Unassigned)
References
Details
(Keywords: uiwanted)
Attachments
(1 file)
39.34 KB,
image/png
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020728
BuildID: 20020728
We need to decide what to do about events on leap year and their reoccurence. Should we repeat them on the 28ths of February, 1sts of March, or only on February 29ths. Or should the user have a choice? I think the user should have a choice either when creating a reoccuring event on leap year or in the preferences. We also need to document the behavior that the user should expect when issues such as this occur.
Reproducible: Always
Steps to Reproduce:
1. Create an event on February 29, 2000.
2. Set it to reoccur every year.
Actual Results:
It reoccurs right now on March 1sts.
Expected Results:
I think the user should have a choice, but if not given a choice, I think the 28th of February makes more sense than the 1st of March.
See http://www.leapdaybabies.com for information. In the following paragraph, they suggest February 29 as the most common choice so we should probably use it.
So when do you celebrate, anyway?
Are you a strict Februarian? Thanks to Kevin Kennelly LDB #14, 1956, for this term, that describes leapers who celebrate their birthday on the last day of February. This seems to be the most popular choice, but if you're undecided check out our party page, for insight into this important question, and ideas for celebrating in leaper style.
Comment 1•23 years ago
|
||
One possible resolution to the problem:
Add the option to either repeat on the "XXth day of February" or the
"Last day of February" for yearly repeating events that occur on February 29th.
(I don't believe that an event that occurs on February 29th should ever repeat
on March 1st.)
To maintain consistency, add the same option for monthly repeating events
created on the last day of the month, except that the text is "XXth day of the
month" or "Last day of the month".
Comment 2•23 years ago
|
||
I think leap year handling should be a separate issue and shouldn't be mixed with
last day of the month, or n-th day of the month events.
By default it should recure on the last day of february but can be reset to *only*
the 29th.
Another issue is to make "last day of month", "first Sunday of the month", etc.
type of events, as many holidays are actually relying on this kind of a recurrence.
Comment 3•23 years ago
|
||
I tend to agree with the setting that 29th February is once in four years, but
the calendar should ask you whether you want to set the reoccurence for each
last day of february.
Simply set the event to recur every 12 months the 29th, and it shows op on the
29th on a leapyear, or the 28th on other years. Maybe just setting a different
label 'last day of the month' for the recur option on 29feb would help.
If you only want to have an event on the leapyears, I think you should set the
event to repeat every 4 years...
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 5•22 years ago
|
||
Default QA Contact for Calendar has changed. If you wish to remain the QA
contact for this bug, feel free to change it back.
QA Contact: colint → brantgurganus2001
Comment 6•22 years ago
|
||
New contact from mikep@oeone.com to mostafah@oeone.com
Filter on string OttawaMBA to get rid of these messages.
Sorry for the spam.
Assignee: mikep → mostafah
I think that the user should have the option of repeating the event every four
years, on February 28th for non-leap years, or on March 1st for non-leap years.
Updated•20 years ago
|
QA Contact: gurganbl → general
Comment 8•19 years ago
|
||
I think the iCalendar standard should be adhered to, and this Bug closed as resolved.
The standards states that such days as 'September 31', 'February 30' do NOT exist as a match within rules.
As we have 2 methods: (a) BYMONTHDAY=29, (b) BYMONTHDAY=-1 to determine what is to occur, we should stick to just simply that (with possibly a warning in help files). And not add any special handling that will, by definition, be non-standard and not be understood outside the Sunbird / Lightning code-space.
Comment 9•19 years ago
|
||
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o
Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Comment 10•17 years ago
|
||
This discussion has been continuing for 6 years now. It does not appear to be that difficult of a situation and considering that we are now in another leap year it seems like a good time to get this fixed.
As mentioned above iCalendar standards are important. They provide clear instructions and enough options to satisfy.
In section 4.3.10 Recurrence Rule: "If BYxxx rule part values are found which are beyond the available scope (ie, BYMONTHDAY=30 in February), they are simply ignored."
-- If an repeating event is every February 29th then it only shows up every 4 years
-- If the last day of February is desired then set a recurring rule for the last day of the month. 3 out of 4 years this will be the 28th and the 29th on leap years.
Both of those options fit cleanly into the iCalendar standards.
Over the 6 years this thread has sat here the only real debate seems to be if the application should provide the user with options or warnings. If desired the application could provide a convenience question to verify the expected behavior. It wouldn't hurt anything to have the options in the application as long as they are translated into the proper standards and any of the scenarios mentioned in this thread can be written in the standard recurring rule.
What is important is the behavior of the application. The current behavior of setting the event to March 1st is just plain wrong. You cannot make one day into another no matter how convenient it might be. It is just a fact of our calendar that February 29th does not occur every year and an event scheduled for the 29th only shows up every four years as well. After all what is the point of having a Leap Year party on March 1st 2009 when 2009 isn't actually a leap year?
Comment 11•17 years ago
|
||
Christian, what do you say about warnings here? Should a warning be displayed? Or should it be ignored and no occurrence shown?
Updated•17 years ago
|
Summary: Decision about event on Leap Year reoccurence needs made. → Handling of yearly recurring events that start on February 29th (Leap Year) is unclear
Comment 13•15 years ago
|
||
Here are my two cents. When a user creates or edits an event which is on February 29, starts on February 29 or ends on February 29, a single selection box should appear. This selection should offer the following options:
- show February 28 for non-leap years (default)
- show only for leap years
- show March 1 for non-leap years
The defaul value has been chosen on the information presented here:
http://en.wikipedia.org/wiki/29_February#Births
When start and end date do not contain February 29, this single selection box should disappear. When such an event is displayed on either February 28 of March 1, a special icon should appear in the calendar overview as to indicate this exception.
I leave to the experts as how this should be represented in the calendar data format. On a functional level, I think the above covers all.
Comment 14•12 years ago
|
||
Another Leap year passed.
No decision yet.
I would stick with comment 8 & comment 10 and keep conorm with the standard --> shows up every 4 years.
Google does it this way.
Outlook shows recurrences on 28th in non leap years automatically.
To keep the user in loop, there should be a hint that a recurrence on 29th of february will only show every 4 years. This hint should also point to the possibility of setting last day of february (or maybe the 60th day of year to get 1st March in non leap years).
I will work on a patch with this premises to drive this issue ahead.
Assignee: nobody → Mozilla
Status: NEW → ASSIGNED
Comment 15•12 years ago
|
||
This notification Box will be schown to the user, to inform that the event will not show every year.
Next step will be to implement this behaviour.
Comment 16•12 years ago
|
||
The box looks good, but maybe it would be nice to put the box at the top of the dialog, so we can also use if for other notifications. See bug 797690.
Comment 17•12 years ago
|
||
I have the box at the top now.
I just can't find the place to add the code to skip the non-leap-years.
It seems, in libical already Mar 1st is passed in as a DTSTART for the occurrence.
I can't find code that gets the dates from the Recurrence-Rule.
Please point out the code section to me.
Flags: needinfo?(philipp)
Comment 18•12 years ago
|
||
Hmm what kind of code are you looking for? You mean the recurrence expansion code in http://mxr.mozilla.org/comm-central/source/calendar/base/src/calRecurrenceInfo.js ?
Flags: needinfo?(philipp)
Comment 19•12 years ago
|
||
I thought it would be this.
I traced the call down to calculateDates(...). But I don't find any RRULE assessment there.
calculateDates() calls to getOccurrences(...) to get the dates, which itself calls to calculateDates() to get the dates for the occurrences???
But the rest seems to be some black magic.
Comment 20•12 years ago
|
||
getOccurrences/getOccurrenceDates calls calulcateDates, which calls getOccurrences on the recurrence *items* (not info). If the recurrence item is an rrule, it will be processed in one of these files (icaljs vs libical):
http://mxr.mozilla.org/comm-central/find?string=calRecurrenceRule
Both use a kind of recur iterator:
http://mxr.mozilla.org/comm-central/ident?i=icalrecur_iterator_new
http://mxr.mozilla.org/comm-central/source/calendar/base/modules/ical.js#4475
that takes care of the expansion.
If you are optimistic, its enough to fix this in ical.js since the change won't make it to the release anyway and I hope to turn on ical.js as a default as soon as the perf issues are out of the way.
Updated•4 years ago
|
Assignee: Mozilla → nobody
Status: ASSIGNED → NEW
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•