Describe the bug
This is a problem with complying with the ISO 8601 standard for weeks. The 29th of December to the 3rd of January may be in a different year than their week belongs to. As an example, January 1st 2021 falls on a Friday. That Friday is in 2020's last week, which is week 53.

This is a problem that the algorithm for calculating which week we currently are in takes into account (getCurrentWeekNum). However, the method below does not take it into account (It is in weekplan_selector_bloc, line 228):

It is a problem, because a week plan might not be entirely in one year, as described earlier, and this if statement presumes that it is. If we take the example from before, the current week will switch to week 1 2021 on that Friday, even though we are still in week 53. This is because the year for that Friday's week plan is marked as 2020, and it'll be caught in the first part of the if statement (2020 < 2021 is true), and so even though we are still in week 53, is it moved to "Overståede uger".

It is not necessarily a problem with January 1st to January 3rd, as we are not very precise with showing the week plan. It's just a bit weird that it will say that we are in week 1 2032, even though we are still in 2031.

This issue has not been observed, as it is not new year at the time of writing, but looking at the code, one can see that it will be a problem.

Expected behavior
The app should be able to handle the edge cases for December 29th to January 3rd.

Actual behavior
The app doesn't handle it, it assumes that every week is fully in a single year.

Proposed solution
Have getCurrentWeekNum return both the week number and which year that week belongs to, then use both in the comparison. This may not work, but it could be a place to start.

Make sure to test isWeekDone thoroughly!

You could possibly reuse the data that is used in testing getCurrentWeekNum. The test can be found here:

The test data can be found in test/blocs/Dates_with_weeks_2020_to_2030_semi.csv. The file looks weird for a CSV file, but it is on purpose, to let both Linux, Windows and MacOS read the file correctly. Do not change it, use the code in the test mentioned before to read it.