-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unconsistency in week Date filter #1805
Comments
That's not necessarily the case - tests are like code, they have bugs too ;) The wanted behaviour here would be for frontend and backend to match up of course. IMHO both should just match what strftime does for |
Thanks for the info, I will double check the d3 to confirm it does the same as python fromisocalendar regarding week handling and summit an updated pull request afterwards. |
You can have a look at the updated #1807 let me know what you think. Side note, in general those who cares about week numbers are mostly european using ISO format for week number, in america we rarely use week number. You can have a read with this here it makes a lot of sense. So I wonder if eventually switching week numbering to ISO could be a better solution? |
Thanks for the fix, I've merged your PR.
I agree that ISO week numbers would probably be a better choice (I personally rarely use week numbers so it doesn't make much a difference to me) |
The week filter is not consistent, there is a 1 week offset when appling a date filter.
For example if you rund the DEMO.
Show the Expenses, and apply the daily interval, with the changes(weekly) display, the expenses are shown per week, as expected.
If you click on the 2017-W36 week, there will be no data shown, to show the 2017-W36 expenses you need to filter the date to 2017-W35.
I believe the proper week is 2017-W36 so there is a -1 week difference in the week date filter?
The text was updated successfully, but these errors were encountered: