Skip to content
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

Summary report shows wrong year #1027

Open
okms opened this issue Jan 3, 2022 · 11 comments
Open

Summary report shows wrong year #1027

okms opened this issue Jan 3, 2022 · 11 comments
Assignees
Labels
bug Something isn't working Priority: high Issue with high priority

Comments

@okms
Copy link
Contributor

okms commented Jan 3, 2022

when viewing the summary report, the wrong year is shown below each week (2020). It appears however that the hours shown are from 2021, which is correct

image

@okms okms added the bug Something isn't working label Jan 3, 2022
@damsleth
Copy link
Member

damsleth commented Feb 2, 2022

This issue does not occur after week 1 2022. Probably related to the dayjs .isoWeek()-bug

@olemp
Copy link
Contributor

olemp commented Feb 16, 2022

This issue does not occur after week 1 2022. Probably related to the dayjs .isoWeek()-bug

Can't reproduce now. What do I need to do to reproduce @okms @damsleth?

@olemp
Copy link
Contributor

olemp commented Jun 2, 2022

This issue does not occur after week 1 2022. Probably related to the dayjs .isoWeek()-bug

Related to #1028?

@damsleth
Copy link
Member

damsleth commented Jun 2, 2022

This issue does not occur after week 1 2022. Probably related to the dayjs .isoWeek()-bug

Related to #1028?

Most likely, yes.
Rolling our own isoWeek algorithm would probably solve both issues

@okms
Copy link
Contributor Author

okms commented Jun 23, 2022

This will most probably happen again 1.jan 2026

@olemp
Copy link
Contributor

olemp commented Dec 13, 2022

This issue does not occur after week 1 2022. Probably related to the dayjs .isoWeek()-bug

Related to #1028?

Most likely, yes. Rolling our own isoWeek algorithm would probably solve both issues

Maybe ChatGPT can make a isoWeek algorithm @okms? ;)

@damsleth
Copy link
Member

damsleth commented Jan 2, 2023

👻 It's back, week 01-2023

image

The data returned from graphql contains hours for
weeks 46 to 52, month 12, year 2022 (correctly), as well as
week 52, month 1, year 2022 (incorrect, should be 2023)
image

Whereas the table seems to be trying to present weeks 46 to 52 2021, as well as week 52 month 1 year 2022.
The effect is that only the 52/01/2022 week is visible in the table, since it's both returned by graphQL and represented in the table.

@damsleth
Copy link
Member

damsleth commented Jan 3, 2023

The plot thickens. The issue does no longer occur as of 03.01.2023 09:00

image

The issue still remains though, that the data for 52/01/2022 (i.e. the part of week 52 of 2021 that falls in 2022), are returned instead of 52/01/2023 (the part of week 52 of 2022 that falls in 2023)

image

@damsleth
Copy link
Member

damsleth commented Jan 3, 2023

We should have a way of simulating the current date to be able to debug this properly

@okms
Copy link
Contributor Author

okms commented Mar 24, 2023

Step 1 in moving forward with this issue is to make test cases where we can specify what date we are testing for

@okms okms added the Priority: high Issue with high priority label Mar 24, 2023
@olemp olemp removed this from the Milestone 11: Sodium milestone Apr 13, 2023
@okms
Copy link
Contributor Author

okms commented May 5, 2023

Lets re-implement this function from scratch and not wait for dayjs to fix this

@olemp olemp added this to the Milestone 13: Aluminum milestone Nov 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Priority: high Issue with high priority
Projects
None yet
Development

No branches or pull requests

3 participants