locked
TimeZone change to UTC while creating or updating the Appointment RRS feed

  • Question

  • I am using EWS 1.2 to send appointments. On creating or updating an Appointment, TimeZone can not be showing Tokyo Standard Time same as ExchangeServer on notification mail and it's TimeZone just be shown to UTC.
    But TimeZone is showing properly When I create or update an Appointment with Outlook.

    Could anyone help me to fix this issue?

    Here is sample code to replicate the issue:

    ExchangeService(ExchangeVersion.Exchange2010_SP2, TimeZoneInfo.FindSystemTimeZoneById("Tokyo Standard Time"));
    service.Credentials = new NetworkCredential(admEmailAddress, userData.Password);
    service.Url = new Uri("https://exchgtest.com/EWS/Exchange.asmx");
    
    //Create an appointment for this user in his email box userAddress.
    service.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, userAddress);
    
    Appointment newAppointment = new Appointment(service);
    newAppointment.Subject = "Test Subject";
    newAppointment.Body = "Test Body";
    newAppointment.Start = new DateTime(2013, 03, 27, 10, 00, 0);
    newAppointment.End = newAppointment.Start.AddMinutes(30);
    newAppointment.RequiredAttendees.Add("test@exchgtest.com");
    
    //Attendees get notification mail for this appointment using UTC timezone
    //Here is the notification content received by attendees:
    //When: Tuesday, March 27, 2013 7:00 PM-7:30 PM. UTC
    newAppointment.Save(SendInvitationsMode.SendToAllAndSaveCopy);
    
    // Pull existing appointment
    string itemId = newAppointment.Id.ToString();
    
    Appointment existingAppointment = Appointment.Bind(service, new ItemId(itemId));
    
    //Attendees get notification mail for this appointment using UTC timezone
    //Here is the notification content received by attendees:
    //When: Tuesday, March 27, 2013 7:00 PM-7:30 PM. UTC
    existingAppointment.Update(ConflictResolutionMode.AlwaysOverwrite, SendInvitationsOrCancellationsMode.SendToAllAndSaveCopy);
    

       
    Monday, May 13, 2013 2:19 AM

Answers

  • This a known issue in Exchange Server.  What version of Exchange are you on?  Please include down to the Roll Up level. For example, Exchange 2010 SP2 RU1.

    The issue is that on Update the server doesn't know what the organizer's time zone is and defaults to GMT / UTC. Therefore, the workaround is to submit the time zone with the update. By default, the EWS Managed API will not submit the time zone if the target server is Exchange 2010.  Here are some workarounds you can employ to resolve this.

    1. When performing an update to an existing meeting set the schema on the ExchangeService object to Exchange 2007 SP1.  The EWS Managed API will submit the time zone if it believes it's targeting an Exchange 2007 server

    2. Use the Visual Studio proxies to build the update request and include the time zone

    3. Manually submit the XML payload and include the time zone.

    Dave


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members.

    Tuesday, May 14, 2013 3:29 PM
  • Hi,

    You didn't include the roll up when you specified the server version. Please install the latest Roll up for Exchange 2010 SP2 (I think it's RU6) and make sure the problem is still there before pursuing the workarounds.

    Workaround #1 is available to you.  When performing an update to an existing item create a new ExchangeService object and set the Requested Version to be Exchange2007_SP1.  This will instruct all calls using that service object to use the Exchange 2007 SP1 schema against the target server.  This will tell the EWS managed API to always build requests based on the 2007 SP1 schema.  The 2007 SP1 schema requires that the time zone be included so the EWS managed API will do it for you.  You will only need to use this schema version for updates.  All other operations can use the 2010 SP2 schema.

    http://msdn.microsoft.com/en-us/library/dd633705(v=exchg.80).aspx 

    2. You can learn more about building and using the VS Proxies by reviewing this documentation : http://msdn.microsoft.com/en-us/library/bb408522(v=exchg.140).aspx

    3. I don't have a ready made sample of this.  This should be your last resort.

    Dave

    • Proposed as answer by Quist Zhang Tuesday, May 28, 2013 7:29 AM
    • Marked as answer by Quist Zhang Tuesday, June 4, 2013 7:21 AM
    Friday, May 17, 2013 8:51 PM

All replies

  • Hi,

    Thank you for posting in the MSDN Forum.

    I'm trying to involve some senior engineers into this issue and it will take some time. Your patience will be greatly appreciated.

    Sorry for any inconvenience and have a nice day!

    Best regards,


    Quist Zhang [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, May 13, 2013 5:44 AM
  • This a known issue in Exchange Server.  What version of Exchange are you on?  Please include down to the Roll Up level. For example, Exchange 2010 SP2 RU1.

    The issue is that on Update the server doesn't know what the organizer's time zone is and defaults to GMT / UTC. Therefore, the workaround is to submit the time zone with the update. By default, the EWS Managed API will not submit the time zone if the target server is Exchange 2010.  Here are some workarounds you can employ to resolve this.

    1. When performing an update to an existing meeting set the schema on the ExchangeService object to Exchange 2007 SP1.  The EWS Managed API will submit the time zone if it believes it's targeting an Exchange 2007 server

    2. Use the Visual Studio proxies to build the update request and include the time zone

    3. Manually submit the XML payload and include the time zone.

    Dave


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members.

    Tuesday, May 14, 2013 3:29 PM
  • I am appreciated for your answer. Target Exchange server is 2010 SP2 and time zone is set to Japan Tokyo Standard Time for our Outlook and Exchange server. 

    I have a few questions for the workarounds here.

    1. You said that the EWS Managed API will not submit the time zone if the target server is Exchange 2010, so the workaround No1 will not be available for us, right?

    2. Could you tell me how to use the Visual Studio proxies to build the update request and include the time zone. I need some details.

    3. Could you give some examples for the XML payload including the time zone?

    Thanks for your help.

    Steven

    Friday, May 17, 2013 6:00 AM
  • Hi,

    You didn't include the roll up when you specified the server version. Please install the latest Roll up for Exchange 2010 SP2 (I think it's RU6) and make sure the problem is still there before pursuing the workarounds.

    Workaround #1 is available to you.  When performing an update to an existing item create a new ExchangeService object and set the Requested Version to be Exchange2007_SP1.  This will instruct all calls using that service object to use the Exchange 2007 SP1 schema against the target server.  This will tell the EWS managed API to always build requests based on the 2007 SP1 schema.  The 2007 SP1 schema requires that the time zone be included so the EWS managed API will do it for you.  You will only need to use this schema version for updates.  All other operations can use the 2010 SP2 schema.

    http://msdn.microsoft.com/en-us/library/dd633705(v=exchg.80).aspx 

    2. You can learn more about building and using the VS Proxies by reviewing this documentation : http://msdn.microsoft.com/en-us/library/bb408522(v=exchg.140).aspx

    3. I don't have a ready made sample of this.  This should be your last resort.

    Dave

    • Proposed as answer by Quist Zhang Tuesday, May 28, 2013 7:29 AM
    • Marked as answer by Quist Zhang Tuesday, June 4, 2013 7:21 AM
    Friday, May 17, 2013 8:51 PM