none
TimeZoneConversionException when converting time from new russian timezone (UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2) to UTC RRS feed

  • Question

  • Hello everyone.

    We developed a program, which works with Exchange Server appointments through EWS Managed API. It was working fine untill we installed recent windows update KB2998527, which is associated with time zone changes in Russia. Now when program attempts to create appointment in Exchange, EWS throws such exception:

    Microsoft.Exchange.WebServices.Data.TimeZoneConversionException: Unable to convert 2014-01-01T00:00:00.000 from (UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2) to UTC. ---> System.ArgumentException: The supplied DateTime represents an invalid time.  For example, when the clock is adjusted forward, any time in the period that is skipped is invalid.
    Parameter name: dateTime
       at System.TimeZoneInfo.ConvertTime(DateTime dateTime, TimeZoneInfo sourceTimeZone, TimeZoneInfo destinationTimeZone, TimeZoneInfoOptions flags, CachedData cachedData)
       at Microsoft.Exchange.WebServices.Data.EwsUtilities.ConvertTime(DateTime dateTime, TimeZoneInfo sourceTimeZone, TimeZoneInfo destinationTimeZone)
       --- End of inner exception stack trace ---
       at Microsoft.Exchange.WebServices.Data.EwsUtilities.ConvertTime(DateTime dateTime, TimeZoneInfo sourceTimeZone, TimeZoneInfo destinationTimeZone)
       at Microsoft.Exchange.WebServices.Data.ExchangeServiceBase.ConvertDateTimeToUniversalDateTimeString(DateTime value)
       at Microsoft.Exchange.WebServices.Data.EwsServiceXmlWriter.TryConvertObjectToString(Object value, String& strValue)
       at Microsoft.Exchange.WebServices.Data.EwsServiceXmlWriter.WriteElementValue(XmlNamespace xmlNamespace, String localName, String displayName, Object value)
       at Microsoft.Exchange.WebServices.Data.EwsServiceXmlWriter.WriteElementValue(XmlNamespace xmlNamespace, String localName, Object value)
       at Microsoft.Exchange.WebServices.Data.AbsoluteDateTransition.WriteElementsToXml(EwsServiceXmlWriter writer)
       at Microsoft.Exchange.WebServices.Data.ComplexProperty.WriteToXml(EwsServiceXmlWriter writer, XmlNamespace xmlNamespace, String xmlElementName)
       at Microsoft.Exchange.WebServices.Data.TimeZoneDefinition.WriteElementsToXml(EwsServiceXmlWriter writer)
       at Microsoft.Exchange.WebServices.Data.ComplexProperty.WriteToXml(EwsServiceXmlWriter writer, XmlNamespace xmlNamespace, String xmlElementName)
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.WriteToXml(EwsServiceXmlWriter writer)
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.EmitRequest(IEwsHttpWebRequest request)
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.BuildEwsHttpWebRequest()
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)
       at Microsoft.Exchange.WebServices.Data.ExchangeService.InternalCreateItems(IEnumerable`1 items, FolderId parentFolderId, Nullable`1 messageDisposition, Nullable`1 sendInvitationsMode, ServiceErrorHandling errorHandling)
       at Microsoft.Exchange.WebServices.Data.Item.InternalCreate(FolderId parentFolderId, Nullable`1 messageDisposition, Nullable`1 sendInvitationsMode)
       at Microsoft.Exchange.WebServices.Data.Appointment.Save(WellKnownFolderName destinationFolderName, SendInvitationsMode sendInvitationsMode)

    This exception is thrown only if ExchangeService object is instantiated with time zone (UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2). If we use different time zone everything is OK. Date of the appointment is not 2014-01-01T00:00:00.000

    So here is the question: why this error may hapen and how it can be fixed?

    Any help will be greatly appreciated.

    Thanks.

    Thursday, October 23, 2014 6:27 AM

All replies

  • Hi, Sergey.

    It seems, that it's a bug in Microsoft.Exchange.WebServices.dll.
    As a temporary fix you can create appointments directly through web services.

    Same error occurs when you use GetUserAvailability.

    Thursday, October 23, 2014 11:12 AM
  • Hi, Sergey.

    Thank you for an answer.

    Can you clarify, what you mean "directly through web services"?


    Sergey

    Friday, October 24, 2014 4:41 AM
  • For example, you can create proxy classes of web service by adding web reference in Visual Studio to Exchange service (/ews/Services.wsdl). 

    And code will be something like this:

    ExchangeServiceBinding esb = new ExchangeServiceBinding
    {
      Credentials = new NetworkCredential(login, password, domain), Url = exchangeUrl
    };

    var attendees = emails.Select(address => new AttendeeType { Mailbox = new EmailAddressType { EmailAddress = address } }).ToArray();

    CalendarItemType appointment = new CalendarItemType
      {
      Body = new ExchangeReference.BodyType { BodyType1 = BodyTypeType.Text, Value = body },
      ItemClass = "IPM.Appointment",
      Subject = subject,
      Location = location,
      RequiredAttendees = attendees,  
      Start = start,
      StartSpecified = true,
      End = end,
      EndSpecified = true
      };

    DistinguishedFolderIdType folder = new DistinguishedFolderIdType { Id = DistinguishedFolderIdNameType.calendar };

    NonEmptyArrayOfAllItemsType items = new NonEmptyArrayOfAllItemsType { Items = new ItemType[1] };
    items.Items[0] = appointment;

    CreateItemType request = new CreateItemType
      {
      SendMeetingInvitations = CalendarItemCreateOrDeleteOperationType.SendToAllAndSaveCopy,
      SendMeetingInvitationsSpecified = true,
      SavedItemFolderId = new TargetFolderIdType { Item = folder },
      Items = items
      };

    CreateItemResponseType response = esb.CreateItem(request);  

    Friday, October 24, 2014 6:02 AM
  • The Managed API has now been open sourced http://blogs.office.com/2014/09/25/ews-managed-api-net-now-open-source/ via GitHub https://github.com/officedev/ews-managed-api . So you should be able to pull the source code and fix the bug yourself (and then submit the change for others to benefit).

    Cheers
    Glen

    Friday, October 24, 2014 6:58 AM
  • Hi Sergey,

    1. Have you found any solution for this issue? Using WebServices directly is rather expensive option in my case as the solution has already been in production and changing it needs a lot of additional efforts for tests, deployment, etc. 

    2. Do you know how can we let MS know about the issue to get the information whether they plan to fix dll? I took a look at MS Connect, but could not find EWS or something similar to post a bug report to.

    Thanks.

    Monday, October 27, 2014 1:35 PM
  • Hi, Mikhail.

    We considered an option to use WebServices directly, but decided, just as you, that this will be too expensive and difficult. The only solution, that I know now is to use non-Russian time zone with EWS. For example, our time zone is UTC+3 Moscow (RTZ2), if we set UTC+3 Bagdad - all works fine.

    I posted similar bug report on EWS Managed API Github page (https://github.com/OfficeDev/ews-managed-api/issues/13).


    Sergey

    Monday, October 27, 2014 1:41 PM
  • You try to set 2014-01-01T00:00:00.000 But, as deffined in  (UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2) TZ deffinition in registry, Moscow uses next TZ in 2014 year:

    Rotate clock forwared for 1 hour on the first Wensday of January (1'st of Jan) at 00:00 and rotate back last Sunday of October (26 of Oct) at 02:00.

    As a result we didn't have time interval from 00:00 till 01:00 on the first of January day.


    MCSE:M 2003, MCITP:EA, SA, EMA, EMA:2010

    Wednesday, October 29, 2014 5:54 AM
  • But I am not trying to set 2014-01-01T00:00:00.000. When creating appointment, I (for example, tested this values) set Start time = 2014-09-09T10:00:00.000, and End time = 2014-09-09T10:30:00.000, then described exception is raised. This is strange.

    Sergey

    Wednesday, October 29, 2014 6:31 AM
  • Thank you very much Sergey!

    This workaround works well for me.

    Thursday, October 30, 2014 10:38 AM
  • I've met the same issue - its happens because .NET (or deeper in OS) has a bug with TimeZone conversions: 

    https://connect.microsoft.com/VisualStudio/feedback/details/1027179/timezone-conversion-bug

    Tuesday, November 11, 2014 2:42 PM
  • This bug appears for all Russian time zones. I used this workaround for Moscow

    var timeZoneInfo = TimeZoneInfo.Local.Id == "Russian Standard Time" ? TimeZoneInfo.CreateCustomTimeZone( "Time zone to workaround a bug", TimeZoneInfo.Local.BaseUtcOffset, "Time zone to workaround a bug", "Time zone to workaround a bug") : TimeZoneInfo.Local; var appointment = new Appointment(service) { Subject = subject, Body = body, Start = start, StartTimeZone = timeZoneInfo, End = end, EndTimeZone = timeZoneInfo };


    Wednesday, November 12, 2014 3:28 PM
  • This bug appears for all Russian time zones. I used this workaround for Moscow

    var timeZoneInfo = TimeZoneInfo.Local.Id == "Russian Standard Time" ? TimeZoneInfo.CreateCustomTimeZone( "Time zone to workaround a bug", TimeZoneInfo.Local.BaseUtcOffset, "Time zone to workaround a bug", "Time zone to workaround a bug") : TimeZoneInfo.Local; var appointment = new Appointment(service) { Subject = subject, Body = body, Start = start, StartTimeZone = timeZoneInfo, End = end, EndTimeZone = timeZoneInfo };



    Thanks, this work for me!
    Wednesday, November 19, 2014 8:22 PM
  • How get Service.GetUserAvailability()  ?

    It`s no parametr for set timezone info


    • Edited by Andrey_S1 Thursday, November 20, 2014 7:28 PM
    Thursday, November 20, 2014 7:28 PM