-
Notifications
You must be signed in to change notification settings - Fork 63
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
Running tests in different timezone #56
Comments
Note that an easy workaround for me to get tests working was to just make sure I had the .env set to America/New_York. Could also just comment it out I guess... |
It would probably make sense and be best if the tests ran across multiple timezones in order to catch deficiencies (e.g., the bug with the timezone-formatting log). I think your suggestion for using the specified timezone with arrow makes sense. The tests all being hard-coded to America/New_York wasn't so much intentional as it was convenient since I live in that timezone, and all of my data to test against in t:connect and Nightscout are also in that tz. I'd suggest making a single test file or section of test files tz-aware first in a PR before starting a massive refactor, just to make sure this approach will work ok. |
That works, can try to commit a test file this weekend |
…faults to using the TIMEZONE_NAME tz in the users .env file, defaults to 'America/New_York' if no .env file. Updated the applicable date strings with -04:00 in test_therapy_event.py and it seems to work for me, test come back ok
I was troubleshooting some issues with the CGM features and wanted to run the tests...
It seems that's not possible outside of the assertequal-assumed timezone of America/New_York (-04:00). The called functions automatically use the .env-specified TIMEZONE_NAME, while the tests use a specific timezone.
It seems like we could...
After thinking about this a second.... I think I'd opt for modifying the tests
"time"
fields to read something like...arrow.get("2021-10-12 00:00:30-04:00").replace(tzinfo=TIMEZONE_NAME).format()
It notes the original test case you had, but makes it clear you're acknowledging the user's timezone should be used since the application functions use it. Any thoughts before I do some search/replace? There's alot of tests involving the timezone in here and I didnt want to do this if there's a better way to approach it...
The text was updated successfully, but these errors were encountered: