github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-06 20:15:33 -05:00
Code Issues 1.5k Packages Projects Releases 55 Wiki Activity

[GH-ISSUE #1062] Scheduled transactions don't handle 29th/30th/31st dates appropriately #49533

New Issue
Open
opened 2026-04-30 11:04:19 -05:00 by GiteaMirror · 12 comments
GiteaMirror commented 2026-04-30 11:04:19 -05:00
Owner
Copy Link

Originally created by @EKCJ on GitHub (May 25, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/1062

Running v23.5.0, when I set up a monthly scheduled transaction starting 31/5 the current behaviour is to not schedule anything for June, because there is no 31st day in June.
image
I'm sure opinions will differ on whether the best option would be to schedule the transaction for 30/6 or for 1/7, I don't have an opinion on that as long as it gets scheduled somewhere. 🙂

Originally created by @EKCJ on GitHub (May 25, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/1062 Running v23.5.0, when I set up a monthly scheduled transaction starting 31/5 the current behaviour is to not schedule anything for June, because there is no 31st day in June. ![image](https://github.com/actualbudget/docs/assets/67192679/7e479f69-838d-475f-9df7-5c060182412a) I'm sure opinions will differ on whether the best option would be to schedule the transaction for 30/6 or for 1/7, I don't have an opinion on that as long as it gets scheduled somewhere. 🙂
GiteaMirror added the scheduleshelp wantedbug labels 2026-04-30 11:04:20 -05:00
GiteaMirror commented 2026-04-30 11:04:21 -05:00
Author
Owner
Copy Link

@EKCJ commented on GitHub (May 25, 2023):

Sorry, just realised I had the wrong tab open and have posted this on docs instead of actual-server. Closed this and will post it in the proper place when I have a minute.

<!-- gh-comment-id:1563245860 --> @EKCJ commented on GitHub (May 25, 2023): Sorry, just realised I had the wrong tab open and have posted this on docs instead of actual-server. Closed this and will post it in the proper place when I have a minute.
GiteaMirror commented 2026-04-30 11:04:21 -05:00
Author
Owner
Copy Link

@Jackenmen commented on GitHub (May 25, 2023):

As a workaround, you can set it to repeat on last day of the month:
Screenshot_20230525_174718_Chrome

<!-- gh-comment-id:1563245872 --> @Jackenmen commented on GitHub (May 25, 2023): As a workaround, you can set it to repeat on last day of the month: ![Screenshot_20230525_174718_Chrome](https://github.com/actualbudget/docs/assets/6032823/a4e1e473-47d1-46e9-918f-4feca92bde03)
GiteaMirror commented 2026-04-30 11:04:21 -05:00
Author
Owner
Copy Link

@Kidglove57 commented on GitHub (May 25, 2023):

I have always used the last day of the month option. In my experience, some payees will take it then and others on the 1st.

Only my view but I think the current option is adequate and probably the only reasonable solution.

I believe there is another issue live for the more thorny problem of payments due on a weekend?

<!-- gh-comment-id:1563270926 --> @Kidglove57 commented on GitHub (May 25, 2023): I have always used the last day of the month option. In my experience, some payees will take it then and others on the 1st. Only my view but I think the current option is adequate and probably the only reasonable solution. I believe there is another issue live for the more thorny problem of payments due on a weekend?
GiteaMirror commented 2026-04-30 11:04:22 -05:00
Author
Owner
Copy Link

@EKCJ commented on GitHub (May 25, 2023):

Many thanks for moving this @j-f1

The last day of month option is useful and does solve the problem for the 31st - however there's still an issue with payments which should always be on the 29th or 30th, even if the month is longer, and only move forward if the month is shorter.

I haven't tried a weekend yet so won't comment on that topic 😅

<!-- gh-comment-id:1563275726 --> @EKCJ commented on GitHub (May 25, 2023): Many thanks for moving this @j-f1 The last day of month option is useful and does solve the problem for the 31st - however there's still an issue with payments which should always be on the 29th or 30th, even if the month is longer, and only move forward if the month is shorter. I haven't tried a weekend yet so won't comment on that topic 😅
GiteaMirror commented 2026-04-30 11:04:22 -05:00
Author
Owner
Copy Link

@rich-howell commented on GitHub (May 25, 2023):

Many thanks for moving this @j-f1

The last day of month option is useful and does solve the problem for the 31st - however there's still an issue with payments which should always be on the 29th or 30th, even if the month is longer, and only move forward if the month is shorter.

I haven't tried a weekend yet so won't comment on that topic 😅

An example would be Feb. If you have something going out on the 30th in January Feb would get ignored and March would pick up again.

The end of the month wouldn't work in the above situation as the 30th isn't the end of the month all the time as @EKCJ pointed out.

This seems like a bug.

<!-- gh-comment-id:1563320412 --> @rich-howell commented on GitHub (May 25, 2023): > Many thanks for moving this @j-f1 > > The last day of month option is useful and does solve the problem for the 31st - however there's still an issue with payments which should always be on the 29th or 30th, even if the month is longer, and only move forward if the month is shorter. > > I haven't tried a weekend yet so won't comment on that topic 😅 An example would be Feb. If you have something going out on the 30th in January Feb would get ignored and March would pick up again. The end of the month wouldn't work in the above situation as the 30th isn't the end of the month all the time as @EKCJ pointed out. This seems like a bug.
GiteaMirror commented 2026-04-30 11:04:23 -05:00
Author
Owner
Copy Link

@Shazib commented on GitHub (Jun 17, 2023):

The package that Actual uses to create the schedules, appears to implement the ICAL spec RFC5545 for date recurrences,

From some cursory googling, I dont think the spec can actually cope with this and thus neither does the package, i think its expected to simply return invalid dates.

image

We would have to define i think, our own behaviour of what we want actual to do with these invalid dates, (e.g. always just forward to the next real date) and apply some logic around the returned occurences.

<!-- gh-comment-id:1595560843 --> @Shazib commented on GitHub (Jun 17, 2023): The [package](https://gitlab.com/john.carroll.p/rschedule) that Actual uses to create the schedules, appears to implement the ICAL spec [RFC5545](https://datatracker.ietf.org/doc/html/rfc5545) for date recurrences, From some cursory googling, I dont think the spec can actually cope with this and thus neither does the package, i think its expected to simply return invalid dates. ![image](https://github.com/actualbudget/actual/assets/4405777/47229267-7b66-4ba7-8a54-ac991ca3b88c) We would have to define i think, our own behaviour of what we want actual to do with these invalid dates, (e.g. always just forward to the next real date) and apply some logic around the returned occurences.
GiteaMirror commented 2026-04-30 11:04:24 -05:00
Author
Owner
Copy Link

@lukepetrolekas commented on GitHub (Aug 3, 2023):

No, an internal system does not need to be created. The ICalendar spec can absolutely handle the case of "last day of month" and "last workday of month" scenarios.

Also From the ICalendar spec definition of Recurrence Relation

The BYSETPOS rule part specifies a COMMA-separated list of values that corresponds to the nth occurrence within the set of recurrence instances specified by the rule. BYSETPOS operates on a set of recurrence instances in one interval of the recurrence rule. For example, in a WEEKLY rule, the interval would be one week A set of recurrence instances starts at the beginning of the interval defined by the FREQ rule part. Valid values are 1 to 366 or -366 to -1. It MUST only be used in conjunction with another BYxxx rule part. For example "the last work day of the month" could be represented as:

FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1

I would suspect the last day of the month could then be specified as:

FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR,SA,SU;BYSETPOS=-1

So long as the rest of the RRULE does not specifically select a date such as the 29, 30, or 31st it will work. It should be implemented as a radio button or some form of either/or scenario.

EDIT: Validated online using rrule.js online demo

<!-- gh-comment-id:1663970540 --> @lukepetrolekas commented on GitHub (Aug 3, 2023): No, an internal system does not need to be created. The ICalendar spec can absolutely handle the case of "last day of month" and "last workday of month" scenarios. Also [From the ICalendar spec definition of Recurrence Relation](https://icalendar.org/iCalendar-RFC-5545/3-3-10-recurrence-rule.html) > The BYSETPOS rule part specifies a COMMA-separated list of values that corresponds to the nth occurrence within the set of recurrence instances specified by the rule. BYSETPOS operates on a set of recurrence instances in one interval of the recurrence rule. For example, in a WEEKLY rule, the interval would be one week A set of recurrence instances starts at the beginning of the interval defined by the FREQ rule part. Valid values are 1 to 366 or -366 to -1. It MUST only be used in conjunction with another BYxxx rule part. For example "the last work day of the month" could be represented as: ` FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1` I would suspect the last day of the month could then be specified as: ` FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR,SA,SU;BYSETPOS=-1` So long as the rest of the RRULE does not specifically select a date such as the 29, 30, or 31st it will work. It should be implemented as a radio button or some form of either/or scenario. EDIT: Validated online using [rrule.js online demo](https://jakubroztocil.github.io/rrule/)
GiteaMirror commented 2026-04-30 11:04:26 -05:00
Author
Owner
Copy Link

@Shazib commented on GitHub (Aug 3, 2023):

As I understood it, selecting a specific date is exactly what is wanted? While having it cope with out of bounds dates for certain months

<!-- gh-comment-id:1664123407 --> @Shazib commented on GitHub (Aug 3, 2023): As I understood it, selecting a specific date is exactly what is wanted? While having it cope with out of bounds dates for certain months
GiteaMirror commented 2026-04-30 11:04:28 -05:00
Author
Owner
Copy Link

@lukepetrolekas commented on GitHub (Aug 3, 2023):

Ok, I put my foot in my mouth back there, you're correct. I did manage to find this, which looks to be the exact same question.

https://stackoverflow.com/questions/35757778/rrule-for-repeating-monthly-on-the-31st-or-closest-day

It's supported by a newer addition called RSCALE, but not all RRULE libraries support it yet.

<!-- gh-comment-id:1664750318 --> @lukepetrolekas commented on GitHub (Aug 3, 2023): Ok, I put my foot in my mouth back there, you're correct. I did manage to find this, which looks to be the exact same question. https://stackoverflow.com/questions/35757778/rrule-for-repeating-monthly-on-the-31st-or-closest-day It's supported by a newer addition called RSCALE, but not all RRULE libraries support it yet.
GiteaMirror commented 2026-04-30 11:04:28 -05:00
Author
Owner
Copy Link

@passabilities commented on GitHub (Apr 3, 2025):

where did we land on this? seems to still be an issue as I'm trying to create a schedule for the 30th and it is not automatically picking up February

<!-- gh-comment-id:2776983482 --> @passabilities commented on GitHub (Apr 3, 2025): where did we land on this? seems to still be an issue as I'm trying to create a schedule for the 30th and it is not automatically picking up February
GiteaMirror commented 2026-04-30 11:04:29 -05:00
Author
Owner
Copy Link

@salomonsters commented on GitHub (Feb 27, 2026):

This issue occurred for me as well. A recurring payment which is slightly regular (company puts it at 29th or before the weekend) so I can't use end of the month for that - it can be as early as the 27th. So in February my rule didn't trigger.
I worked around it by changing it to 28, manually selecting the transaction and applying the rule, then reverting it back to the 29th. But quite convenient and definitely a bug imho that I would love to see fixed.

<!-- gh-comment-id:3974499461 --> @salomonsters commented on GitHub (Feb 27, 2026): This issue occurred for me as well. A recurring payment which is slightly regular (company puts it at 29th or before the weekend) so I can't use end of the month for that - it can be as early as the 27th. So in February my rule didn't trigger. I worked around it by changing it to 28, manually selecting the transaction and applying the rule, then reverting it back to the 29th. But quite convenient and definitely a bug imho that I would love to see fixed.
GiteaMirror commented 2026-04-30 11:04:29 -05:00
Author
Owner
Copy Link

@RMcGhee commented on GitHub (Mar 8, 2026):

@passabilities @salomonsters
There's a PR that would fix this: https://github.com/actualbudget/actual/pull/7156
But I think it's very much worth a discussion about whether it's the right path forward.

<!-- gh-comment-id:4020246450 --> @RMcGhee commented on GitHub (Mar 8, 2026): @passabilities @salomonsters There's a PR that would fix this: https://github.com/actualbudget/actual/pull/7156 But I think it's very much worth a discussion about whether it's the right path forward.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug help wanted schedules
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#49533
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?