Hi Chris,

It's working for me with 7852 and an EAS connected Samsung phone. Has the account the correct time zone configured? Do you have the correct time zone when you enable "Show Time Zones" in the new appointment 

window?

Best Regards,

Reto

Hello and good morning. I just wanted to let you know that we have this issue on our list and hope to have a fix in the near future. Please keep an eye out for our next release. Have a good one!

Hello Reto

Timezone is correct ad webmail and also on the samsung S21 and Samsung S20:

UTC+1 for Rome,Bern,Amsterdam and so on.

Only full day or multiple day appointments are affected. if i do a appointment with time than it's correct.

Hy Kyle

Many thanks for this information. is there a workaround because all EAS Android devices have that problem and our customers are not so happy about that.

best regards chris

You're very welcome Chris, happy to help! I am not aware of any workarounds currently, so recommend users leverage webmail temporarily while we get a fix in place for this. Have a good one!

I had scheduled an update to latest build this night, I think I will hold it. Thank you for reporting this here, it would have been again a new support nightmare...

Kyle:

"I just wanted to let you know that we have this issue on our list and hope to have a fix in the near future. "

Is it possible to have these known issues reported on a page or a sticky community post, for latest builds, so we can refer to it BEFORE applying the updates. There really need to be a place where to find reported/confirmed issues for builds so we don't update and then find ourselves in trouble.

Especially when builds doesn't allow to rollback due to changes in files.

It would be really much better than having to constantly read all the community posts to dig for possible issues with new builds.

Thanks

As noted, I was able to replicate these behaviors and had escalated the case to development for further review. You will be pleased to know that we've identified a fix for the issue (involving UTC offsets) and this fix will be available in our next public release build which should be available later today (tentatively.)

@Sébastien Riccio that is an excellent idea, and I'd be happy to suggest it for you. That being said, this issue (and likely many others) evolve quickly and often are resolved and ready for testing before we update our release notes page! I'm sure we can do this for any issues which are taking longer to investigate and resolve though, I'll get this noted with product management. Have a good one!

@Kyle well for this particular issue I would have been in trouble if I wasn't randomly browsing the community pages to look what's going on and was going to do the update this night.

I really think as soon as an issue with the latest available build is identified and confirmed, it should immediatly be listed in a "current known issue" sticky thread.

It's true that in some cases the issues can be quickly resolved (custom build, and then in a new release) but even better than resolve the issue is to completly avoid the issue by not updating to the problematic build and waiting for the next one.

Also sometimes the problem are resolved in custom build but can take some time to be released to public through a release. In the meantime, informing your customer about the issues in a dedicated thread would avoid a lot of trouble for your customers that are blindly updating to a build that have new issues.

This could spare us and ST team many time and efforts around known issues.

Kind regards.

I definitely see your points here Sébastien, and I've noted your feedback with our teams here.

That being said, this issue was confirmed late yesterday afternoon, and now has a fix available for it as of this morning, so as you can see things happened pretty quickly on this one :)

@Kyle: information/notes about "confirmed bugs" and about fixes available in custom builds should be pinned/linked or example on top at download-page or release-notes-page.

It is really a pain that your "public releases" often include serios issues (like EAS or EWS-protocol/syncing issues, different calendar issues again and again and again...) Most of your releases are public - if there are still "fatal" issues it does not look like really beta testing is happening before each release. I already suggested two SmarterMail-branches: "stable" and "beta" - and first put a new version into the stable branch.

And the idea by Sébastien is good, at least confirmed bugs / and custom build wiht fixes shoud be mentioned and kept always up2date!

This has been noted, thank you for your feedback Thomas.

@Chris, sorry. I didn't see that it was only all day. 

I really like the idea of a list of bugs of the current release, better would be a full access to the bug database.

I would also like to have custom builds available on the license page. Asking for an existing custom build takes time, especially for us here in Europe due to the time difference. 

@Reto: custom build downloads available for immediate download is a great suggestion.

and of possible with changelog/what is being fixed 

This is fixed in the public release Build 7859.  It was any all-day appointments with a positive UTC timezone configured syncing to any EAS device.

Hi all, 

The issue with all-day appointments being offset by a day has been resolved in Build 7858: 

We appreciate your patience as we worked through this. 

This is why we need a license-holder-only tracker. So we know of confirmed reported issues, issues ST knows about and are working on, reported issues that are not yet confirmed etc. instead of having to do through the community forums.

Hello All

Thanks for all the answers and comments. i can confirm that with public av. build 7859 the problem is solved. thanks to ST for that fast fix.

i also would suggest a kind of license-holder-only tracker and/or also the possibility for some not public av. fixed releases.

cheers chris

I updated to build 7859 over the weekend. EAS behaves still strange. A customer complained, that many calendar entries disappeared.

Logs are showing, that SmarterMail has sent a delete command to the client, which caused the deletion of the calendar entries. Fortunately the calendar entries where not deleted on the server, still visible oin the WebMail. This is odd.

---

Personally i  got deleted folder in EMail back. A folder deleted long long time ago came back to life. Also some folder showed double or had "[1]" in the name.

I'm not sure, if build 7859 fixed the EAS issues.

Martin,

When an EAS client sees a new version of the protocol it will re-download your mailbox and if a folder was lost on your client for some reason but still existed on the server, that folder will be re-sent back to the client.  We have little to no complaints regarding our new EAS implementation and if you think something isn't working properly, please open a support ticket so we can take a look at it.

@Tim: I noticed for me that changing/updating an existing appointment @iPhone will not upodate/sync the new values/content successfully to our SmarterMail-server (running build 7859). I will create a support ticket for this tormorrow - for today it is already too late here I will have to get some sleep.

btw: first/initial creation of a new appointment @iPhone is ok/working and being synced to SmarterMail-server, but it looks like further updates/changes @iPhone are having issues.