452716 - new improved way to specify schedule recurrence pattern [extension fodder]

Status: RESOLVED WONTFIX

(Calendar :: Lightning Only, enhancement)

Description

[Marcus Yoo]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Lightning 0.8

The current recurrence pattern is very limited.
In addition to not being able to specify lunar based dates,
there are two other types of recurring dates that can not be easily specified.

Case 1: dates relative to specific dates other then the 1st or last of month.
Example: US election day.
There are several different ways to state the US general election date.
One way is to say "the 1st Tuesday on or after Nov 2nd".
Current recurrence pattern specifier has
- repeat "annually" every "nth" "weekday" of "month"
This could be more generalized to say
- repeat "annually" every "nth" "weekday" on or after "month/day", or
- repeat "annually" every "nth" "weekday" prior to "month/day".
If the "month/day" specified is "month/1" (first day of month), that is equivalent of the currently available specification.

Case 2: Date relative to another schedule/holiday dates
Example: Black Friday
The Black Friday is the day after Thanksgiving.
Since Thanksgiving day itself is not "fixed" (4th Thu in Nov),
Black Friday can not be specified relative to any fixed date.
To enable this type of dates, we need
- "nth" "day/week" before/after "another holiday selection".
This comes in very handy when specifying e.g. ash wednesday relative to easter.

I also have a better US holidays.ics and Korean Holidays.ics.
I was told to submit bug and attach the file, but I can not find where to attach my file... you may want to clarify that at the bottom of the webpage http://www.mozilla.org/projects/calendar/holidays.html


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Marcus Yoo]

ok, I found where "attachment" can be added.
please ignore the last paragraph.
the rest of the enhancement request is still valid.

Comment 2

[Pete Riley]

Case 1:
> repeat "annually" every "nth" "weekday" on or after "month/day", or
> repeat "annually" every "nth" "weekday" prior to "month/day".

I would like this too.  You can probably simplify "on or after" to just "after".  For example, I think Election Day is the first Tuesday after November 1st.

Case 2:
I think that relative dates (e.g. the Easter-related holidays that are before/after Easter) are covered by bug 242499.  Unfortunately, the comments in that bug cover many different topics but the bug title refers to Easter.

Comment 3

[Marcus Yoo]

I used "on or after" because that equates to
- nth weekday in month
being the same as
- nth weekday on or after 1st of the month
Otherwise, you would need to specify
- nth weekday after the last day of the previous month
I'd prefer "on or after" scenario better.
Plus, I think that "on or after" works out more intuitive.
When combining that logic with "prior to", it will leave no gap or overlaps.
I.e.,
if you have "after 1st of month" and "prior to 1st of month", that will leave the actual date, the 1st, out of the equation,
and if you have "on  or after 1st of month" and "on or prior to 1st of month", then the 1st of the month could show up in both,
so you will have to set one to be inclusive, the other exclusive.
"On of after" (inclusive)
"Prior to" (exclusive)


BTW,
I concur regarding the 2nd case (relative dates, easter calculation) is fully covered in 242499, and can be dropped from this thread. (Though the subject does need to be debated more in that other thread...)

Comment 4

[Simon Paquet [:sipaq]]

As stated here and various places elsewhere by other developers and me:

The ICAL-standard offers very powerful ways to express various recurrence
options, but exposing every last possible option to the user would make the
current recurrence dialog totally unusable.

This is an area that would be best served by an extension, that would try to
implement various more complex recurrence options, that the majority of users
will likely never need, but that a minority would like to use. An extension
would also be a great place to try to innovate in how to present those options
to the user trough the UI.

If someone would then come up with a great proposal validated by a well-used
extension, we may revisit this decision.

--> WONTFIX

Comment 5

[Pete Riley]

> Case 1:  repeat "annually" every "nth" "weekday" on or after "month/day"

Marcus, I was thinking more about Case 1.  I like the idea and I would use it for Election Day on my calendar, but I'm thinking that it's not justified to add it to the UI just for U.S. holidays.  I can't think of any other common use for this, can you?

Especially in the case of a holiday calendar (which doesn't change very often), I think that it might be better to keep the UI as clean as possible and just manually change the RRULE in the ics file for this event.  This assumes that Lightning won't undo the manual edit the next time that it loads the ics file.

For example, I Googled and the RRULE for Election Day is something like this (must be on two lines because of limited line lengths):
RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,
   5,6,7,8

I know it's not as easy, but you only have to add this rule once for Election Day and it will work forever.  The people in the Lightning community (in the forums & newsgroups) would probably be happy to help with uncommon RRULEs like this.

> The current recurrence pattern is very limited.

Perhaps it would be good if advanced users had a way to manually edit an event's RRULE string via the Recurrence Dialog without needing to manually edit any external files (which could be on inaccessible servers).  This functionality could be hidden from the UI by default.

Comment 6

[Philipp Kewisch [:Fallen][☁️📆]]

(In reply to comment #5)
> Perhaps it would be good if advanced users had a way to manually edit an
> event's RRULE string via the Recurrence Dialog without needing to manually edit
> any external files (which could be on inaccessible servers).  This
> functionality could be hidden from the UI by default.

I think this could easily be done in an extension, while its not the greatest UI, it would certainly fit for advanced users.