Should recurring expenses be date-based, without choosing an exact time?

[krokosik]

I’m considering simplifying recurring expenses by removing the option to choose an exact hour and minute. Before changing this, I’d like to hear whether anyone relies on that functionality.
The proposal is to configure which dates an expense repeats on—daily, a particular weekday, a day of the month, or the last day of the month—without specifying a clock time. SplitPro would handle processing internally; execution at a particular hour would no longer be part of the recurrence settings.

Why change this?

Exact times introduce considerably more complexity than I anticipated when implementing recurring expenses. Honestly, I was a bit naive with the original design: translating a recurrence into a cron job seemed straightforward, but calendar dates, timezones, and existing expenses make it much less straightforward.
Two reported issues illustrate this:

• Month-end expenses scheduled on the wrong date Recurring expense set to "last day of the month" is saved and executed on the 1st of the following month #762. Midnight on the last day of the month in one timezone can fall on the previous day in the scheduler’s timezone. A recurring rule such as “the day before the last day” cannot always be expressed by the scheduler. A simple timezone adjustment can therefore change what the recurrence actually means.
• Duplicate expenses when the initial expense already covers the first occurrence Duplicate recurring expense created on same day as initially added expense #698. If you enter a future-dated expense and set it to repeat on that same date, the scheduler can create another expense for an occurrence you already entered. Exact execution times add another distinction to reconcile with expenses that users interact with as dates: has this occurrence already been recorded, or should it still be generated?
  Removing the time selection would not automatically fix these bugs—we still need consistent date handling and duplicate prevention. But it would give us a much simpler model: this recurrence produces an expense for this date, rather than promising execution at a particular local clock time.

It would also fit the rest of SplitPro better

Regular expenses let you choose a date, without choosing a time. Expense dates elsewhere in the app are also presented without a time of day.
Making recurrences date-based would bring them into line with that experience, simplify the editor, reduce timezone-related setup, and make scheduling bugs easier to fix reliably.

Do you rely on exact times?

Would removing the hour/minute selection affect your workflow? If so, please describe the use case—especially if you need multiple occurrences per day or an expense to appear at a particular hour.
This is a proposal for feedback, not an announced change.

[krokosik]

Tagging potential recurrence users
@AlanMW @bybv @cosmologist10 @gravelfreeman @guenzd @Hund @minseungchoi @phobiac @Pipe-Runner @rossnick @sevenlayercookie @Silther @sloria @Timmy93 @ZenoBell

[Timmy93]

I confirm that for me having only the date is sufficient.
Having the correct date also in "edge" cases and without repetition would be fantastic

[Silther]

I have multiple recurring expenses but all of them are set to 1:00.
Hourly precision is not really needed as many of my recurring transactions are not even debited at the same day each month much less the same hour.

[FelixDz]

We also use recurring expenses on our instance, and I confirm we don't need more than day precision.