[GH-ISSUE #844] [Feature] Add options/setting for first day of the week #7270

New Issue

GiteaMirror · 2026-04-10T17:01:40-05:00

GiteaMirror commented

2026-04-10 17:01:40 -05:00

Originally created by @mkalamarz on GitHub (Apr 2, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/844

Verified feature request does not already exist?

I have searched and found no existing issue

💻

Would you like to implement this feature?

Pitch: what problem are you trying to solve?

When selecting a date ina date-picker it is confusing that Sunday is displayed as first day of the week because in Poland it is meant to be Monday.

I found no setting to change "First day of week" to "Monday".

Describe your ideal solution to this problem

Ideal solution consists of:

Adding "First day of week" option/setting under "Settings" next to the date format (as this is a date-specific setting).
Saving the value as integer in the database (or wherever you store it, local storage, cache, etc.)
Making the date-picker respect that setting's value

I'm not an APP dev, but as far as I could tell Actual uses Pikaday for the date-picker. In it's documentation there is a firstDay option that is meant just for that. So it should be fairly easy to implement for someone who eats React for breakfast.

Even if I'm mistaken (about Pikaday), this is such a basic setting that every single date-picker or date-specific tool shoud have it at your (dev) disposal.

PS I guess it could be dane based on user's locale but I feel like it's better to make user select it manually.

Teaching and learning

In my opinion all that's needed is to update Settings > Formatting docs page as the setting is self-explanatory and anyone needing to change it will know what it does (as in every other app).

Originally created by @mkalamarz on GitHub (Apr 2, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/844 ### Verified feature request does not already exist? - [X] I have searched and found no existing issue ### 💻 - [ ] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? When selecting a date ina date-picker it is confusing that Sunday is displayed as first day of the week because in Poland it is meant to be Monday. I found no setting to change "First day of week" to "Monday". ### Describe your ideal solution to this problem Ideal solution consists of: 1. Adding "First day of week" option/setting under "Settings" next to the date format (as this is a date-specific setting). 2. Saving the value as integer in the database (or wherever you store it, local storage, cache, etc.) 3. Making the date-picker respect that setting's value I'm not an APP dev, but as far as I could tell Actual uses [Pikaday](https://github.com/Pikaday/Pikaday) for the date-picker. In it's documentation there is a `firstDay` option that is meant just for that. So it should be fairly easy to implement for someone who eats React for breakfast. Even if I'm mistaken (about Pikaday), this is such a basic setting that every single date-picker or date-specific tool shoud have it at your (dev) disposal. PS I guess it could be dane based on user's locale but I feel like it's better to make user select it manually. ### Teaching and learning In my opinion all that's needed is to update [Settings > Formatting docs page](https://actualbudget.github.io/docs/Getting-Started/using-actual/settings#formatting) as the setting is self-explanatory and anyone needing to change it will know what it does (as in every other app).

GiteaMirror added the feature label 2026-04-10 17:01:40 -05:00

GiteaMirror closed this issue

2026-04-10 17:01:41 -05:00

GiteaMirror commented

2026-04-10 17:01:42 -05:00

@j-f1 commented on GitHub (Apr 2, 2023):

This is a good idea! I’m reluctant to add another formatting option here since IMO the best option would be to have the calendar match the current user locale. However, a quick look through the Intl API (and some frustrating conversations with chatgpt) suggest there’s no easy way to extract the appropriate first day of the week for the user’s locale.

@j-f1 commented on GitHub (Apr 2, 2023): This is a good idea! I’m reluctant to add another formatting option here since IMO the best option would be to have the calendar match the current user locale. However, a quick look through the `Intl` API (and some frustrating conversations with chatgpt) suggest there’s no easy way to extract the appropriate first day of the week for the user’s locale.

GiteaMirror commented

2026-04-10 17:01:43 -05:00

@rich-howell commented on GitHub (Apr 2, 2023):

This is a good idea! I’m reluctant to add another formatting option here since IMO the best option would be to have the calendar match the current user locale. However, a quick look through the Intl API (and some frustrating conversations with chatgpt) suggest there’s no easy way to extract the appropriate first day of the week for the user’s locale.

Could you get the current day of the users locale and calculate the beginning of the week from there if there is nothing available within the API?

@rich-howell commented on GitHub (Apr 2, 2023): > This is a good idea! I’m reluctant to add another formatting option here since IMO the best option would be to have the calendar match the current user locale. However, a quick look through the `Intl` API (and some frustrating conversations with chatgpt) suggest there’s no easy way to extract the appropriate first day of the week for the user’s locale. Could you get the current day of the users locale and calculate the beginning of the week from there if there is nothing available within the API?

GiteaMirror commented

2026-04-10 17:01:44 -05:00

@j-f1 commented on GitHub (Apr 2, 2023):

Looks like date-fns has the necessary info!

@j-f1 commented on GitHub (Apr 2, 2023): Looks like `date-fns` has the necessary info!

GiteaMirror commented

2026-04-10 17:01:46 -05:00

@biohzrddd commented on GitHub (Apr 16, 2023):

What about changing the "New File" workflow to have a single "Setup" screen where the user is shown all the settings that will be used? They can name the file, then change any default settings before hitting "Create".

If this is accepted by most, I could mock something up. It would be good to reuse the current Settings function though I may need help understanding if the settings are global to all files or per-file. If the settings aren't per-file, that may need to be a separate issue before attacking this.

@biohzrddd commented on GitHub (Apr 16, 2023): What about changing the "New File" workflow to have a single "Setup" screen where the user is shown all the settings that will be used? They can name the file, then change any default settings before hitting "Create". If this is accepted by most, I could mock something up. It would be good to reuse the current Settings function though I may need help understanding if the settings are global to all files or per-file. If the settings aren't per-file, that may need to be a separate issue before attacking this.

GiteaMirror commented

2026-04-10 17:01:46 -05:00

@j-f1 commented on GitHub (Apr 16, 2023):

What about changing the "New File" workflow to have a single "Setup" screen where the user is shown all the settings that will be used? They can name the file, then change any default settings before hitting "Create".

I like that the current workflow puts you right into getting your budget set up without asking a bunch of questions (hence I’d prefer an automatic option that checks based on the current locale for the most natural experience.

If the settings aren't per-file, that may need to be a separate issue before attacking this.

fyi: all the settings in the web app are per-file (the electron app also has a setting about where to put its files on disk which is global)

@j-f1 commented on GitHub (Apr 16, 2023): > What about changing the "New File" workflow to have a single "Setup" screen where the user is shown all the settings that will be used? They can name the file, then change any default settings before hitting "Create". I like that the current workflow puts you right into getting your budget set up without asking a bunch of questions (hence I’d prefer an automatic option that checks based on the current locale for the most natural experience. > If the settings aren't per-file, that may need to be a separate issue before attacking this. fyi: all the settings in the web app are per-file (the electron app also has a setting about where to put its files on disk which is global)

GiteaMirror commented

2026-04-10 17:01:47 -05:00

@github-actions[bot] commented on GitHub (May 1, 2023):

✨ Thanks for sharing your idea! ✨

This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=is%3Aissue+label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc

Don’t forget to upvote the top comment with 👍!

@github-actions[bot] commented on GitHub (May 1, 2023): :sparkles: Thanks for sharing your idea! :sparkles: This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution). The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=is%3Aissue+label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc Don’t forget to upvote the top comment with 👍!

GiteaMirror commented

2026-04-10 17:01:47 -05:00

@mkalamarz commented on GitHub (May 5, 2023):

@MatissJanis as this got implemented in 23.5.0, shouldn't there be an "Implemented" tag or some kind of bot/human notice here? I'm not sure how in this new "feature requests get closed" setup should we distinguish "closed but please vote" from "closed but in development" and "closed and implemented" etc.

@mkalamarz commented on GitHub (May 5, 2023): @MatissJanis as this got implemented in 23.5.0, shouldn't there be an "Implemented" tag or some kind of bot/human notice here? I'm not sure how in this new "feature requests get closed" setup should we distinguish "closed but please vote" from "closed but in development" and "closed and implemented" etc.

GiteaMirror commented

2026-04-10 17:01:48 -05:00

@j-f1 commented on GitHub (May 5, 2023):

That would be great to have automated!

Remove the “needs votes” and “help wanted” and “good first issue” labels
Collapse the automated comment as outdated
Maybe post a new comment when the release hits?

@j-f1 commented on GitHub (May 5, 2023): That would be great to have automated! - Remove the “needs votes” and “help wanted” and “good first issue” labels - Collapse the automated comment as outdated - Maybe post a new comment when the release hits?