It seems that we don't send the time zone header in the request to save a message created through EmailMessage.Bind(service, id).CreateForward().Save(...). This means that when we open the message in outlook the sent time is displayed in UTC and not the local time the client is using.
To reproduce, just run the following snippet and inspect the text content of forwarded.Body.Text, or check the email in the Drafts folder, to see that it the date is returned in the UTC time zone and not the local time zone. If you are living in a location that are running on UTC, you can manually specify the time zone to something else in the ExchangeService constructor.
var id = "INSERT_MAIL_ID_HERE";
var ewsUrl = "INSERT_EWS_URL_HERE";
var service = new ExchangeService(ExchangeVersion.Exchange2013_SP1)
{
Url = new Uri(ewsUrl),
};
var message = EmailMessage.Bind(service, id);
var forwarded = messsage.CreateForward().Save(WellKnownFolderName.Drafts);
forwarded.Load();
I think the simplest fix will be to override the GetIsTimeZoneHeaderRequired method of the ServiceObject to return true in the derived ResponseMessage.cs class, but I am not sure if that will negatively impact any other part of the library.
I am willing to create a pull request if this fix seems reasonable.
It seems that we don't send the time zone header in the request to save a message created through
EmailMessage.Bind(service, id).CreateForward().Save(...). This means that when we open the message in outlook the sent time is displayed in UTC and not the local time the client is using.To reproduce, just run the following snippet and inspect the text content of
forwarded.Body.Text, or check the email in the Drafts folder, to see that it the date is returned in the UTC time zone and not the local time zone. If you are living in a location that are running on UTC, you can manually specify the time zone to something else in theExchangeServiceconstructor.I think the simplest fix will be to override the
GetIsTimeZoneHeaderRequiredmethod of theServiceObjectto return true in the derivedResponseMessage.csclass, but I am not sure if that will negatively impact any other part of the library.I am willing to create a pull request if this fix seems reasonable.