Reminders being sent using UTC instead of configured timezone. #877
Labels
No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/vikunja#877
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
My timezone is "America/Halifax" which is UTC-3.
I set up a reminder for a task for 8:00am (local time), but I got the email at 11:00am (local time), which would be 8:00am UTC.
I have to conclude that reminders are being sent using UTC instead of the configured timezone.
I also noticed that.
The problem is all dates in the db (not just reminders, also due dates, start/end dates etc) are stored in utc. Then when you retrieve the tasks it will return them in the configured time zone which will then be used to show the dates in your browser.
Now, when the api collects these dates on the server it simply checks every minute if there are any reminders due in the next minute and it ignores the configured time zone in that case because it will just do
select * from task_reminders where reminder between now() and now() + 1 minute(pseudocode).The conversion of stored time zone (which is always utc) and returned time zone is handled by the orm and this seems to bypass this (Might be a bug in the orm?).
Ideally, there'd be a setting to set the time zone per user which would let multiple users get the reminders in their specific time zone.
The time left before the due date is calculated correctly, i.e., "due in 30 minutes", is this done in the same manner?
The due date seems to be using my local time but the reminder seems to be using UTC.
I think your idea is correct though: ideally, everything on the API side should deal with nothing but UTC except when a date is presented to a user (in which case it should be converted to that user's local timezone) or a user is allowed to enter a date (in which case it should be accepted in that user's local timezone and then converted to UTC for the API).
All dates you see in the browser are (or should, at least) based on the time zone in your browser.
That's interesting - it should always show the time in the time zone in the browser. Can you reproduce this on try? (try runs in
Europe/Berlin, notAmerica/Halifaxbut the conversion mechanics are the same)The browser sends the date in an iso timestamp with the time zone, the api then does all the converting to utc before saving it into the db.
First, without setting an email address, how can I verify that the reminder time is being interpreted correctly?
Even without considering that, I tried to enter times in Berlin time, but the time until due is being calculated against my local time. (see attachments).
Ah that was more to verify the issue with the due date being displayed in another time zone in your browser. Try does not send emails - and they would certainly arrive at the utc time anyway.
That seems correct.
No, it wasn't correct. Timezone stuff is always confusing...I'll try to break it down.
The time you see in the browser should be in the time zone of your browser. Could be a bug though. The api returns the dates in berlin time, but as an iso time stamp. If I implemented the formatting method correctly, your browser should understand that and convert it to your local time when displaying. Assuming your browser and os are correctly configured to use your local time.
This is how it looks in my browser:
And this is what is saved in the db:
Did you set the date to 1pm or 6pm (from your browser)? Because it saved 9pm, which would be correct in utc if you'd set it to 6pm in your time but not 1pm in berlin time:
I start to feel like the whole "just let the browser convert the time zones" makes this more complicated overall.
This could indicate the conversion only worked one way, but not when loading again - or something like that.
Now is a good time to view this Tom Scott video again 🙂
Ha. I've watched that video. I think I got things wrong from the start when I tried to reproduce this with 'try'. I set my times to what I thougth was Berlin time, but I was actually setting them to my local time -- 5 hours in my future.
So I guess this begs the question: If all the timestamps are sent in UTC (whether explicitly or via a local time with offset), then what is the point of having a configuration value for TimeZone? It seems like this could be much simpler with the API always dealing with UTC and the frontend always converting it to the frontend's local time.
In the end, it does't really matter how it's working as long as I can understand it and adjust for it :)
I agree with that. I've added the time zone setting when migrating all the unix timestamps to iso dates. Back when I made that change I needed a time zone to return the dates in but in retrospect it does not make that much sense. I guess we could deprecate the setting and move the reminders over to a user setting - then at some point maybe also the formatting in the browser to use that same setting.
Closing this as I belive it has been solved, please ping if you're still having issues with it.
Just confirmed this one. Thanks!