Time Zone Problem

[Nicding]

When I forwarding the mail, in mail content history, the sent time of the last mail is always shown in UTC time zone.

The correct time is:

I have tried to change my local time zone, change time zone of my email account and change param timezone in Account class. But none of them worked.

Do you have any suggestion on this?
Thank you so much for your time.

[alejcas]

I don't know what your problem is. Maybe you have to explain this in more detail.

Read #364

[Nicding]

Thank you very much for your reply.

Let me explain this issue in more detail with an example:
I received a mail at 10:19 AM (UTC+8). And if I replied this mail manually, in mail content history, the receiving time of this original mail is shown correctly in my local time zone (UTC+8).

But if I replied the same mail by python-o365, in mail content history, receiving time is shown in time zone UTC+0

If there is any concern, please feel free to let me know.
Thank you very much.

[alejcas]

Ok! I understand it now. Let me do some tests

[alejcas]

Ok, this library saves the datetimes always in UTC.

I was supposing that the Outlook interface convert datetimes to your local timezone but it seems that when replying from OWA it's not doing it.

I test this on the Outlook desktop app and it shows all datetimes in your local timezone.

Maybe we should save the datetimes on the local timezone defined instead of UTC.

I'll meditate this further.

@Narcolapser what do you think?

[Nicding]

Thanks for your reply.

I also did some further investiagtion during last few days.
I tried to use outlook REST API directly, and found the receiving time had already become wrong in body.content in reponse.
So I thought this issue might be an issue of Office 365 API.
I read the API document and found very little information about the time zone. I tried to added the header Prefer: outlook.timezone="Asia/Shanghai", and it also didn't work.

Hope above information could help.

[alejcas]

@Nicding thanks! That’s very useful

[Narcolapser]

I to will have to think a bit. Presumably, there wouldn't be any harm in saving in the local time zone as long as you mark it as such. It will need to be in the hands of the app developer though. Since we don't know what application someone is making we don't know if timezone could change on us or not.

Digging into the code, it looks like all interactions with the API are assuming UTC, is that what you were referring to with "I was supposing that the Outlook interface converts datetimes"? In such a case, would it be hard to add some sort of check on whether to set the "__received" value to local or utc?

[alejcas]

The library gets datetimes in any timezone and converts to the local timezone.
The library saves datetimes only in UTC (it converts from local timezone to UTC).

What I was supposing is that the Outlook interface should convert any saved datetime to the local timezone before showing the datetime to the user.

And in fact it does this at least when using the Outlook desktop app.

I think this is because of this... but I'm not sure.

# when saving or sending drafts:

if self.created:
    message[cc('createdDateTime')] = self.created.astimezone(pytz.utc).isoformat()
if self.received:
    message[cc('receivedDateTime')] = self.received.astimezone(pytz.utc).isoformat()
¡if self.sent:
    message[cc('sentDateTime')] = self.sent.astimezone(pytz.utc).isoformat()

Should we save always in the user defined timezone?

[Narcolapser]

I think that's going to be the behavior that the user expects. As in, if I'm not working with multiple time zones then everything should be in mine. Would it be difficult to have that as the default behavior with the option to specify your timezone?

[alejcas]

I think that's going to be the behavior that the user expects. As in, if I'm not working with multiple time zones then everything should be in mine. Would it be difficult to have that as the default behavior with the option to specify your timezone?

Then we should implement this change.
This is a breaking change.

I'll see how to achieve that.

[alejcas]

After analysing this, the library should not send UTC datetimes to the server.
I'll change this soon