EWS based calendar sync with MS Exchange fails caused by timezone problem

Hi Whoever might feel responsible,

we are currently evaluating eM Client as an alternative to MS Outlook in our company environment. 
And all looks very promising, especially the handling of the Email client is very intuitive, nicely featured and animated (big acknowledgement), if there wouldn’t be a Calendar based sync problem with our MS Exchange 2016 server via Enterprise Web Services (EWS).

Syncing of Emails, Contacts, Tasks are working fine (… initially).
But there seems to be a bug in the eM Client towards the timezone conversion by syncing the Calendar with MS Exchange 2016 (probably also 2013) using EWS:

General error msg. of the Email client is:


(The settings are correct and the server’s EWS via https is available):

I have a background as Java developer and know a little bit, how to interprete an exception stack trace, and this would be in Java a classical IllegalArgumentException caused by a NullPointerException:

required stack trace log:

12:43:27 [email protected] [Exchange Web Services]  Synchronizing folder '[email protected]/Calendar/'
12:43:27 [email protected] [Exchange Web Services]  MailClient.Accounts.ConnectionException: Invalid timezone. Id: W. Australia Standard Time, DisplayName: (UTC+08:00) Perth, Standard name: Standard, Daylight name: null ---\> System.ArgumentException: Invalid timezone. Id: W. Australia Standard Time, DisplayName: (UTC+08:00) Perth, Standard name: Standard, Daylight name: null ---\> System.ArgumentNullException: Value cannot be null.
12:43:27 Parameter name: value
12:43:27    at VObject.Values.Text..ctor(String value)
12:43:27    at VObject.CalendarProperties.TzName..ctor(String value)
12:43:27    at MailClient.Schedule.TimeZone.TimeZoneConvert.ToiCalendar(TimeZoneInfo timeZoneInfo)
12:43:27    --- End of inner exception stack trace ---
12:43:27    at MailClient.Schedule.TimeZone.TimeZoneConvert.ToiCalendar(TimeZoneInfo timeZoneInfo)
12:43:27    at MailClient.Storage.Schedule.TimeZone.Data.TimeZoneRegistry.StoreTimeZone(TimeZoneInfo timeZone)
12:43:27    at MailClient.Storage.Schedule.Data.DbScheduleRepository.Store(IScheduleRepositoryItem evnt)
12:43:27    at MailClient.Storage.Data.DbRepository`1.Add[ST](Object senderContext, IEnumerable`1 items)
12:43:27    at MailClient.Storage.Attachment.Data.ItemWithAttachmentRepositoryAdapter`1.Add[ST](Object senderContext, IEnumerable`1 items)
12:43:27    at MailClient.Storage.Application.ItemCollection`2.AddRange(IEnumerable`1 items, CancellationToken cancellationToken)
12:43:27    at MailClient.Storage.Application.ItemCollection`2.AddRange(IEnumerable`1 items)
12:43:27    at MailClient.Protocols.Common.ItemSynchronizeContext`2.StoreItems(SynchronizationType synchronizationType, IEnumerable`1 newItems)
12:43:27    at MailClient.Protocols.Common.ScheduleItemSynchronizeContext`1.StoreItems(SynchronizationType type, IEnumerable`1 newItems)
12:43:27    at MailClient.Protocols.Common.ItemSynchronizeContext`2.Synchronize[T](SynchronizationType synchronizationType, IEnumerable`1 items, Func`2 getUniqueId, Func`3 hasChanged, Func`2 isDeleted, Func`2 convertItems, Action`2 updateItem)
12:43:27    at MailClient.Protocols.Exchange.ExchangeItemSynchronizer`2.Synchronize(IItemSynchronizeContext`1 synchronizeContext, Folder folder, CancellationToken cancellationToken)
12:43:27 &nbsp; &nbsp;at MailClient.Protocols.Common.ItemSynchronizer`2.\<\>c\_\_DisplayClass28\_0.<enqueuesynchronize>b__1(WorkerStatus status, CancellationToken cancellationToken)<br>12:43:27    at MailClient.Protocols.Exchange.ExchangeGenericCommand.Execute(WorkerStatus status)<br>12:43:27    --- End of inner exception stack trace ---<br>12:43:27    at MailClient.Protocols.Exchange.ExchangeGenericCommand.Execute(WorkerStatus status)<br>12:43:27    at MailClient.Commands.Command.Process(WorkerStatus status)</enqueuesynchronize>

The problem in this case is the semantic cause for the Exception. 

By handling a null value as Daylight attribute of the TimeZoneInfo parameter to the method: ToiCalendar(TimeZoneInfo timeZoneInfo) and its underlying process logic.

Then there are several time zones in the world without daylight saving:

    (UTC) Coordinated Universal Time
    (UTC) Monrovia, Reykjavik
    (UTC+01:00) West Central Africa
    (UTC+02:00) Harare, Pretoria
    (UTC+03:00) Baghdad
    (UTC+03:00) Kuwait, Riyadh
    (UTC+03:00) Nairobi
    (UTC+04:00) Abu Dhabi, Muscat
    (UTC+04:00) Port Louis
    (UTC+04:00) Tbilisi
    (UTC+04:30) Kabul
    (UTC+05:00) Islamabad, Karachi
    (UTC+05:00) Tashkent
    (UTC+05:30) Chennai, Kolkata, Mumbai, New Delhi
    (UTC+05:30) Sri Jayawardenepura
    (UTC+05:45) Kathmandu
    (UTC+06:00) Astana
    (UTC+06:00) Dhaka
    (UTC+06:30) Yangon (Rangoon)
    (UTC+07:00) Bangkok, Hanoi, Jakarta
    (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi
    (UTC+08:00) Kuala Lumpur, Singapore
    (UTC+08:00) Perth
    (UTC+08:00) Taipei
    (UTC+08:00) Ulaanbaatar
    (UTC+09:00) Osaka, Sapporo, Tokyo
    (UTC+09:00) Seoul
    (UTC+09:30) Darwin
    (UTC+10:00) Brisbane
    (UTC+10:00) Guam, Port Moresby
    (UTC+11:00) Magadan, Solomon Is., New Caledonia
    (UTC+12:00) Coordinated Universal Time+12
    (UTC+13:00) Nuku’alofa
    (UTC-01:00) Cape Verde Is.
    (UTC-02:00) Coordinated Universal Time-02
    (UTC-03:00) Buenos Aires
    (UTC-03:00) Cayenne, Fortaleza
    (UTC-04:00) Georgetown, La Paz, Manaus, San Juan
    (UTC-04:30) Caracas
    (UTC-05:00) Bogota, Lima, Quito
    (UTC-06:00) Central America
    (UTC-06:00) Saskatchewan
    (UTC-07:00) Arizona
    (UTC-10:00) Hawaii
    (UTC-11:00) Coordinated Universal Time-1
    (UTC-12:00) International Date Line West

So I assume an MS Exchange Server setup, using the server system time of one of these time zones above, wouldn’t have set a Daylight attribute value, and Microsoft simply leaves it blank (null value) in the EWS backend, like in our case for the timezone (UTC+08:00) Perth.

So in my opinion basically the application logic in the source code of eM Client towards the TimeZone conversion in the Calendar feature needs to be altered slightly to consider this fact, and catching the exception and set an internal default value, if required.

But also for architectural improvement of the sync process via EWS in future:

I did go a bit further and wanted to see, if in general a bug by processing the Calendar folder sync feature via EWS has an impact on the other functionalities synced via EWS (Contacts and Tasks) into the eM client?

So I changed the contact details of one user object in MS Exchange’s global address book entry.
And it seems, that this change never reaches the eM Client anymore after the syncing problem of the Calendar folder has occurred for the first time.
No matter how often you press the refresh button initiating the re-sync operation or simply restart eM Client, the error message above just pops up (see screenshot) and that’s it.
In this case the Global Contact list is not going to be synchronized with the server anymore. 
Mails are!!! But I assume they are using another protocol (MAPI via https or classical IMAP? I didn’t look to much into it… )

In this case I’d suggest to change the EWS sync implementation a bit, by designing the process of the EWS sync independent from each other for each functionality. 
So that the Calendar, Contacts, Tasks functionality application-internally are using the EWS based sync process more independently, and if one of those features is going to fail caused by an error, like in our case syncing the Calendar folder, the other functionalities like Contacts and Tasks are not affected, more independent and would be still in sync with the server.

So rather give each functionality its own EWS sync process application-internally, or redesign the common EWS based process that way, e.g. by implementing threads for each of the functionalities, Calendar, Contacts, Tasks, which then can fail independently without affecting the others

I hope this helps…

Otherwise my eM client experience feels just awesome, and it is definitely worth the consideration to swap MS Outlook for it. :slight_smile:

Cheers,
Andreas

Update: problem is experienced with current eM Client version: 7.0.27943.0

Hi,

I believe that this problem is fixed in our internal version already so if you email me at [email protected] I’ll send you a link for download. Thank you.

GW