-
-
Notifications
You must be signed in to change notification settings - Fork 43
Fixes timezone problem in execute_chore #51
Conversation
Thank you for your work, is there a way to achieve this without adding 2 more dependencies? Seems like this could be in the Std lib. |
To the best of my knowledge, there's only a partial one. It would be possible to use timezone , which is in the datetime module, to do the actual timezone correction, but it needs to know the time delta from UTC (i.e., timezone, daylight savings info, etc.). AFAIK, the only way to get that information from the OS is tzlocal , which would pull in pytz anyway. There's a fairly ugly hack that can get the delta for the timezone alone, but that doesn't help with DST, etc., corrections throwing it off. |
Seems like travis flagged your PR as abuse, I'll have to check this. |
Thank you, I contacted Travis CI about that abuse thing |
Travis issue should hopefully be resolved but we need another commit to trigger the build. Could you change something, e.g. remove the empty line added or add something to a comment please? |
I did that, and also fixed up the requirements, but Travis is still failing once it gets to the coverage run step. Not sure what the problem is. |
Best reviewed: commit by commit
Optimal code review plan
|
Description
The API call behind execute_chore expects either a UTC time or a local time including an appropriate time zone , whereas Python's datetime.now returns a local time without time zone information; this causes chore executions to be assigned the wrong time (for example, in CST (-6), all chore executions appear 6 hours into the future.)
The code in this pull request attaches the local timezone to the tracked_time before submitting it.
Related issue (if applicable): fixes issue 13 in lovelace-grocy-chores-card (bug found here)
Checklist