O365 / python-o365

A simple python library to interact with Microsoft Graph and Office 365 API
Apache License 2.0
1.6k stars 411 forks source link

TimeZone Handling #1051

Open alejcas opened 5 months ago

alejcas commented 5 months ago

The current implementation of O365 as of today (2.0.32) is wrong when handling timezones.

The current implementation:

  1. will request to msgraph all dates in utc
  2. will define a timezone to work with: either use the provided timezone or get the local system timezone or fallback to utc
  3. then will convert all date times to the previous defined timezones to present the info to the user
  4. will enforce all date times to be protocol.timezone if it is provided even when the user explicitly provides a different timezone
  5. when saving messages, events, etc. will sometimes convert the date times to utc (not all the time)

The plan for 2.1.0 is to remove all this mess so:

  1. will not request msgraph dates in utc (not using header Prefer: UTC), but rather work with the date times the api provides case by case.
  2. will define a default timezone to work with: This timezone will be the user provided timezone or the local system timezone or fallback to utc.
  3. will then present date times to the user converted to the defined timezone. If a date time comes without a timezone, the date time timezone will be replaced with the timezone defined before (it's and assumption and can be wrong in edge cases).
  4. when saving whatever object to the cloud will send whatever timezone is define case by case...

At least this is the plan

This is a huge change in terms of timezone handling... Be aware

alejcas commented 5 months ago

This will address #368 as well

tylerlittlefield commented 1 month ago

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 message.received information, how should I be handling/correcting the timestamp associated with it?

alejcas commented 1 month ago

The library will convert to your local timezone automatically.

tylerlittlefield commented 1 month ago

Thanks, so if my project has a requirement to convert timezones based on the mailbox which the email came from, I could:

  1. Ensure the server running the code has a timezone defined, say UTC
  2. Consume emails from O365 like normal (it will use servers timezone and emails will be converted from emails source timezone to UTC)
  3. Convert the UTC timezone to whatever timezone the mailbox requires, e.g. GMT

Do you see any problem with this?

alejcas commented 1 month ago

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.

tylerlittlefield commented 1 month ago

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?

alejcas commented 1 month ago

But don’t use pytz. Instead use zoneinfo objects

tylerlittlefield commented 1 month ago

I got stuck trying to use Protocol() to set the timezone, I'll just make sure I know what timezone the server is running. Thank you for the prompt responses!