Since we updated to v100, customers also reported issues about calendars. We first thought it could be a mail client problem, but reports about issues increased over time since then.

It's taking way too much time for us to debug issues and report them, when it was working quite well in v16... 

Hi Neal, 

This issue has been addressed in the latest release. We found that it occurred because iOS does not put the timezone name when it syncs created/modified appointments. It includes only the UTC offset, and there are many timezones that share the same UTC offset. In Build 7117, we added the code to better handle this. For modified appointments, SmarterMail will try to use the existing timezone. For new appts, it will check whether the user's timezone is included in the list of potential time zones with the same UTC offset. If not, it will check the server timezone. If that fails, it will fall back to using the first timezone with the specified offset.

I'm sorry to hear that we've lost your trust in SmarterMail. We take your feedback seriously and hope this is something we can rectify.

The change log is actually incorrect, if you create appointments from any EAS client it was in error. In my work with Kyle I clearly explained appointments created from MS Outlook and also Win10 mail had the same issues (all EAS clients). It is NOT an issue with appointments created from iOS. I suggest you all continue to work this issue as I think your hack is destined to fail again. iOS probably doesn't use Windows timezones nor does Android. They use Olson Timezones such as Windows Eastern is America/New_York in Olson timezone. It's not "flaky EAS" as your staff want to pawn this issue on, it's your implementation or lack of understanding of the API per client. In addition simple testing would find this before us. 

Hello Neal. I wanted to chime in here because I noticed something that needed clarification. You have mentioned before that these issues stem from any EAS usage, but I was unable to reproduce this through extensive testing. It was only when the iOS devices involved in my test lab were used that we started seeing timezone issues and shifts in dates/times. I believe this issue on the iOS side essentially "bubbles up" over time causing further shifts as additional edits/updates are completed. 

Now that the timezone selection issue has been resolved there, we believe the remaining shift issues should clear up as well. Can you please retest sending updates from your different clients and let us know if you still see these issues? In my own testing I am now unable to reproduce the issues you were seeing at all. As you're aware this is both a good and a bad thing as it makes testing a little more complicated. Happy to help get to the bottom of these issues though. Thanks in advance Neal!

Prior to the fix: Create an appointment in MS Outlook starting on Day 1 at 2 PM and ending on several days later at 11 AM. No time zones selected. View the appointment on any iOS device and it showed an ALL DAY event. The event as outlined above did not have to originate on an iOS device, any EAS device creating an appointment would do this. iOS would READ the appointment wrong and show it as an ALL DAY.

After the new build that fixes this I had to go into each calendar appointment, turn on all day, turn off all day, verify times and resave. Something was synced to the server odd either with time zones or ALL DAY that had to be reset per above. So far my appointments are stable but I'll monitor as time goes on.