-
Notifications
You must be signed in to change notification settings - Fork 424
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
TimeZone Handling #1051
Comments
This will address #368 as well |
I am using 2.0.34, so assuming current implementation is still being used. Wanted to ask, is there a recommendation for how to handle timezones reliably in current state? For example, I am using the |
The library will convert to your local timezone automatically. |
Thanks, so if my project has a requirement to convert timezones based on the mailbox which the email came from, I could:
Do you see any problem with this? |
Account has a timezone parameter that will default automatically to your system timezone, but you can provide whatever timezone you want. O364 will convert all datetimes to this timezone. |
Got it, so lets say an east coast mailbox receives an email (4AM EST). If I connect using: Account(..., timezone=pytz.timezone("America/Los_Angeles")) And then fetch that email, the timestamp should be 1AM PST right? |
But don’t use pytz. Instead use zoneinfo objects |
I got stuck trying to use |
The current implementation of O365 as of today (2.0.32) is wrong when handling timezones.
The current implementation:
The plan for 2.1.0 is to remove all this mess so:
At least this is the plan
This is a huge change in terms of timezone handling... Be aware
The text was updated successfully, but these errors were encountered: