Monthly Repeating Tasks for "Last Day of the Month"

[PapaZhans]

This is utilized in many other task platforms and is very helpful for bill paying and other reasons. If it wouldn't be too difficult to integrate, please consider it. You have an awesome project!

[ulsklyc]

Context from #974, which touched the same function.

While checking this wish I found a bug underneath it, and it was not the one the numbers suggested: Math.min(targetDay, lastDay) never took effect, because setUTCMonth() had already rolled over on a date still carrying the 31st. Short months did not fall back to their last day - they fell out entirely. A monthly task on the 31st arrived in seven months out of twelve, and with INTERVAL=2 the rhythm broke on top of that.

before:  01-31 -> 03-31 -> 05-31 -> 07-31 -> 08-31 -> 10-31 -> 12-31
after:   01-31 -> 02-28 -> 03-28 -> 04-28 -> 05-28 -> 06-28 -> 07-28

That is fixed and shipping. What is not fixed is the residue, and it is exactly what this wish would solve: the next occurrence is computed from the clamped date, so a series begun on 31 January stays on the 28th from February onwards. For that to stop, the rule has to carry the intended day - which is BYMONTHDAY.

Two things that are worth deciding together with it rather than after it:

• BYMONTHDAY=-1 on its own covers "last day of the month" and means the same thing here and in any calendar this syncs with. General BYMONTHDAY would also cover "on the 15th", which already works by creating the series on the 15th - and BYMONTHDAY=31 would mean something different here than in RFC 5545, which drops the occurrence in short months instead of clamping it.
• The yearly branch has the same missing anchor (Eine jaehrliche Serie am 29. Februar rutscht dauerhaft auf den 28. #978): a series on 29 February never returns to the 29th, not even in the next leap year.

No decision made yet - this is a note so the connection is not lost.

[ulsklyc]

Decided, and implemented in #983: BYMONTHDAY=-1 only, together with the yearly anchor from #978.

The repetition form gets one new choice, "on the last day of the month", and it appears only under "monthly". That is the one statement a start date cannot express, because it means a different day every month. "On the 15th" needs no field - you create the series on the 15th - and BYMONTHDAY=31 would mean something different here than in RFC 5545, which drops the occurrence in short months instead of clamping it. A field that means one thing in Yuvomi and another in the calendar it syncs with would be worse than no field.

The reason #978 came along is that both had the same cause: the intended day was derived from the previous occurrence, so a clamp in a short month rewrote it for good. Where the caller knows DTSTART - calendar expansion, ICS parser, series arithmetic - it now passes it through as an anchor, and a yearly series on 29 February comes back in the next leap year. Task series get no anchor: a task series is a chain of separate rows with no memory of its origin. Nothing existing is migrated.

A BYMONTHDAY other than -1 stays a foreign rule: the form does not read it, therefore does not rebuild it, and it survives an edit verbatim.

[ulsklyc]

Shipped in v2.61.0, @PapaZhans. The repetition form has a new choice under "monthly": on the last day of the month, whatever length that month has.

One correction to my earlier comment here. I wrote that it was implemented in #983, and the behaviour changed after that in #984. The server does not move your start date onto the first occurrence. If you create a series on the 15th with "last day of the month", the entry keeps the 15th and the calendar shows 31 January as the first appointment - the rule is applied when the series is displayed, not written into the record. Pulling the date at save time was tried and taken back: the reminder, the lead time and the follow-up instance all read that date directly, and none of them would have learned that the server changed it.

Two consequences worth knowing. In a task, the rule describes the next run only - the task stays due on the date you entered, and the run after you complete it lands on the month end. The hint under the switch says so in each module now, because one shared sentence was a promise that only held in the calendar. And an Outlook push sends such a series without its recurrence rather than with a different one: Graph has no absolute last-day pattern, and the closest-looking substitute selects a different day.

Existing series are untouched. Related, from the same work: a yearly series on 29 February now returns in the next leap year instead of dropping to the 28th for good.