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.

Sign up for GitHub

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

Jump to bottom

Fix timezone issues #29

Open
slatcarf opened this issue May 21, 2024 · 2 comments
Open

Fix timezone issues #29

slatcarf opened this issue May 21, 2024 · 2 comments
Assignees
@slatcarf
Labels
bug Something isn't working

Comments

@slatcarf
Copy link
Collaborator

slatcarf commented May 21, 2024 •
edited
Loading

For example let's say we insert a task group with initialStartdate 23.05.2024:00:30 in frontend -> to utc its 22.05.2024:22:30
Then we compare the initialStartDate::date with the date from NOW()::date but ::date just removes the time, so the initialStartDate becomes 22.05.2024. Now we compare it with the current date on lets say 22.05.2024:14:30 in our timezone which is 22.05.2024:12:30 in UTC. The date will be truncated so we compare with `22.05.2024. So the scheduler will actually create assignments for this task group despite the initial start date still being in the future.
@slatcarf
Copy link
Collaborator Author

Solved by removing the date cast and also comparing times and always storing task assignments created_at as if they happened at the beginning of the day.

@slatcarf slatcarf self-assigned this May 22, 2024
@slatcarf slatcarf added the bug Something isn't working label May 22, 2024
@invertedEcho
Copy link
Owner

we still have timezone stuff in our app, e.g. getStartOfInterval assumes the user is of UTC+2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@slatcarf slatcarf

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@invertedEcho @slatcarf