Skip to content
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

Open
alejcas opened this issue Feb 1, 2024 · 8 comments
Open

TimeZone Handling #1051

alejcas opened this issue Feb 1, 2024 · 8 comments
Assignees

Comments

@alejcas
Copy link
Member

alejcas commented Feb 1, 2024

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
Copy link
Member Author

alejcas commented Feb 1, 2024

This will address #368 as well

@tylerlittlefield
Copy link

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
Copy link
Member Author

alejcas commented May 22, 2024

The library will convert to your local timezone automatically.

@tylerlittlefield
Copy link

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
Copy link
Member Author

alejcas commented May 22, 2024

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
Copy link

tylerlittlefield commented May 22, 2024

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
Copy link
Member Author

alejcas commented May 22, 2024

But don’t use pytz. Instead use zoneinfo objects

@tylerlittlefield
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants