Additional information just discovered - a Google calendar recipient gets the meeting request for one hour after the proposed time.  i.e. a 4.30pm appointment shows up in Google as being 5.30pm.

So maybe it is in fact a timezones & DST-related issue.

Hi Bert,

Can you upgrade to the latest build, 7242 (released Nov. 1) and see if this is still happening?  Since you have Maintenance and Support on your license I'd like to get a support ticket open for you if this continues after doing an upgrade.

Hi Emily,

Ok will upgrade tomorrow (Friday) night and then attempt to reproduce the problem again.

Hi Emily,

This issue is still recurring after the update to 7242.

What's the next step?

Hi Bert,

Since you still have Maintenance and Support on your license I've started a support ticket from this thread for you.

We have the same calendar and email issue with timezone -03: 00 Brasilia.

Daylight Saving Time has been canceled in Brazil, but I don't know why SmarterMail interprets it as if it had Daylight Saving Time ... emails arrive 1 hour in advance, calendars don't work ...

We're seeing same issue. Ha. I thought I was going crazy. Seems to happen on recurring appointments mostly generating from Outlook. In outlook the timezone says PST (UTC -8), but in Smarter Mail web interface and also EAS connected clients the appointment says just UTC with no offset.

I'm so glad it isn't just me... :D

I have a support ticket open with Kyle at the moment.  While he hasn't been able to reproduce the issue thus far, so will keep working on it with him.

Has this been recognized as a bug yet?

Is this still an ongoing thing?

Testing EAS now and all day events created on my desktop in the +8 timezone show up on my mobile (also +8 timezone) as starting at 8am on the expected day going on until 8am the next...

Non all day events show as the correct time/offset.

Webmail shows everything correctly.

(Server is in utc timezone)

This started happening again when NZ went back into DST.  Appointment requests and accepted appointments were all over the show.  Customers started complaining again, and I told them I was looking into upgrading to SM 17 over the Christmas holiday break (summer holidays NZ).  Due to several issues with SM 17 I held off, until a customer threatened to leave due to this as well as other issues with mobile devices (Samsungs and Samsung Mail/Calendar apps over EAS) not recording accepted appointments in their calendars (also affected me personally). 

In the last week of February, I accepted that most of the SM 17 upgrade issues as well as bugs were solved in the 18th Feb release.  I upgraded from SM 16.x to SM 17.

It seems sorted!

Customers have reported some existing appointments are still wrong, however all new appointments being set up are so far in the correct time slot. The accepted appointments bug has also been sorted and appointments are showing in calendars when accepted on mobile devices.

My advice is to give up on SM 16.x or earlier, and move to v17.  

Though I could start a half dozen threads on odd things observed after the upgrade (dead appointments reappearing, folders with [1] after them) for the most part the issues were minor annoyances that could be easily solved by end users themselves.

I repeat: My advice is to give up on SM 16.x or earlier, and move to v17.  

Thank you Bert for that extensive reply :)

I have done more investigating and found out it seems to be an issue with "All day events" that are added to SM from Outlook via CalDAV (in my case using https://caldavsynchronizer.org/).

Whilst they are correctly shown as all day events in Outlook itself and also the webmail interface (the correct toggle button is clicked) - once they get to android they are no longer "All day events" (the toggle is set to a normal time span event).

Only happens with the CalDAV events - anything created on the mobile or via webmail synchronises properly.

I've put in a ticket :)

(And yes, this is on v17)

We`re on SM 17 Build 7719 and on GMT+2 and since about a week ago, all our appointments have gone haywire. Generally it seems that appointments generated in WebMail and responded to in Webmail are OK, but anything that involves Outlook (EAS or MAPi) or other mobile clients, if we create or respond to appointments from these clients, the hours will be moved forward with 1 or 2 hours. We have a ticket opened and hope it will be solved soon as obviously this is a major headache for our (or any) business.

Hi again

Ionel are you in the Southern Hemisphere - so are on DST right now?

This is the sort of behavior I had been observing. It went away when DST ended (GMT+12). When DST started again (GMT+13), it came straight back. But now seems resolved in SM17.

Outlook would often display a bar along the top of the meeting subject saying something like "this meeting was created in a different timezone" when in actuality no it hadn't been, everything is in NZDT (GMT+13).

It would affect external Outlooks as well as Google calendars. It really seems to be something wrong on the SmarterMail side of things.

I agree it's a major major headache. Please post here again if/when you get a resolution. If it happens again to me & my customers, then I'll be reposting about it here and I can and will open another support case now that I've moved to SM 17.

Hi,

No, we`re in the Northern Hemisphere, in Romania. DST will start on March 28 here and ends in October 31. We`ve had issues at the end of last year as well when DST ended, but now there have been no changes related to DST here since October. Our issue is now ongoing.