AquaMail Forum
English - Android => Bug reports => Topic started by: jupi24 on June 24, 2016, 09:45:41 am
-
I created a recurring appointment in Outlook/Exchange that lasts a day and repeats every year (birthday).
AquaMail syncs that appointment one day later than entered. I rechecked the date by calling the OWA web interface of our Exchange server. Here the appointment is shown at it's correct date. So I think it's Aquamail that's faulty.
Test multiply repeated. Android 4.4 and 6.01 behaves the same. Aquamail version is 1.6.1.5.
See attached files.
-
Please update to 1.6.2 -- the current is 1.6.2.5 -- there have been some fixes.
Then use web mail or Outlook to change something about the appointment (the color should be enough) and "refresh" in your Calendar app.
If the issue remains, please capture the issue in the app's debug log (see below). With the log enabled, repeat the above steps then send me the log file so I can see the app's communication with the Exchange server.
-
Please update to 1.6.2 -- the current is 1.6.2.5 -- there have been some fixes.
Then use web mail or Outlook to change something about the appointment (the color should be enough) and "refresh" in your Calendar app.
If the issue remains, please capture the issue in the app's debug log (see below). With the log enabled, repeat the above steps then send me the log file so I can see the app's communication with the Exchange server.
I'm running the latest version of AquaMail and have a calendar bug.
The issue is that certain calendar events imported from Exchange are appearing on the following day.
This is only happening to one event. All other events are fine. (Yes I have tried resyncing the calendar)
Looking at the iCal files of events that sync correctly and those that don't, I notice that the event that doesn't sync has a empty TZID, whereas the correct events have a TZID. Both events have TZOFFSETs.
Sent from my SM-G920F using Tapatalk
-
If an event doesn't have a TZID, then what happens to the actual time zone is "murky" --
-- Aqua Mail has some "fallback" logic but so does Exchange (when syncing calendar events in an Exchange account, the app doesn't get original ICAL data, rather it gets Exchange's already parsed representation of that).
If you wish to pursue it, please:
- Check how the event shows in Exchange web mail / calendar
- If it's what you expect it to be, then:
- Please enable Aqua Mail's debug log including "raw session data" (a link to instructions is below in my signature).
- Use web mail / calendar to change the event's color / category
- Back to Android, in the Calendar app, Menu -> Refresh (or Sync, etc.), let it finish, make sure the event's color does update (meaning that Aqua Mail processed the change)
- Send the debug log to support / at / aqua-mail / dot com, and please let us know the *expected* (correct) date/time of the event.
-
If an event doesn't have a TZID, then what happens to the actual time zone is "murky" --
-- Aqua Mail has some "fallback" logic but so does Exchange (when syncing calendar events in an Exchange account, the app doesn't get original ICAL data, rather it gets Exchange's already parsed representation of that).
If you wish to pursue it, please:
- Check how the event shows in Exchange web mail / calendar
- If it's what you expect it to be, then:
- Please enable Aqua Mail's debug log including "raw session data" (a link to instructions is below in my signature).
- Use web mail / calendar to change the event's color / category
- Back to Android, in the Calendar app, Menu -> Refresh (or Sync, etc.), let it finish, make sure the event's color does update (meaning that Aqua Mail processed the change)
- Send the debug log to support / at / aqua-mail / dot com, and please let us know the *expected* (correct) date/time of the event.
How are you guys going with this issue?
Sent from my SM-G920F using Tapatalk
-
Re: How are you guys going with this issue?
Did you collect / send a debug log for this?
-
Re: How are you guys going with this issue?
Did you collect / send a debug log for this?
It was sent on the 18th March. If you asking it sounds it was like not received or lost in the plethora of emails. I have resent the log. Cheers
Sent from my SM-G920F using Tapatalk
-
Re: It was sent on the 18th March. If you asking it sounds it was like not received or lost in the plethora of emails. I have resent the log. Cheers
Got it last night and sent you a new build with a workaround.
The server is reporting this event as being in the UTC time zone -- and since UTC doesn't have daylight savings, this recurring event that spans the daylight savings turning on / off is going to be off by one hour for half the year.
The workaround was to (still) properly match the "deleted instances" / "updated instances" which until then Android wasn't able to do: for some reason the server is still reporting those (the instances) based on the proper time zone, so they are shifted by one hour vs. what Android expects (based on the UTC time zone of the "master" recurring event).
I can't fix the real underlying issue - the server says the event is in the UTC time zone, the app has no reason or way to second-guess that.
-
Re: It was sent on the 18th March. If you asking it sounds it was like not received or lost in the plethora of emails. I have resent the log. Cheers
Got it last night and sent you a new build with a workaround.
The server is reporting this event as being in the UTC time zone -- and since UTC doesn't have daylight savings, this recurring event that spans the daylight savings turning on / off is going to be off by one hour for half the year.
The workaround was to (still) properly match the "deleted instances" / "updated instances" which until then Android wasn't able to do: for some reason the server is still reporting those (the instances) based on the proper time zone, so they are shifted by one hour vs. what Android expects (based on the UTC time zone of the "master" recurring event).
I can't fix the real underlying issue - the server says the event is in the UTC time zone, the app has no reason or way to second-guess that.
Kostya, please let me know if you need any more info. As requested I havr provided you with a log on 12th April.
Sent from my SM-G920F using Tapatalk
-
Re: Kostya, please let me know if you need any more info. As requested I havr provided you with a log on 12th April.
I've seen it and did respond.
In short, I did not find any evidence for an Aqua Mail bug.
The app stored your event's data as expected - start date, a simple recurrence pattern, a few deleted instances.
-
Re: Kostya, please let me know if you need any more info. As requested I havr provided you with a log on 12th April.
I've seen it and did respond.
In short, I did not find any evidence for an Aqua Mail bug.
The app stored your event's data as expected - start date, a simple recurrence pattern, a few deleted instances.
Here's some more details:
- Outlook app on Andriod correctly shows the appointment in their Calendar. Outlook doesn't sync with Google's Calendar.
- Blue Mail, correctly syncs the appointment in Google's Calendar. (Actually Blue Mail overall is quite good)
- 9 mail Also correctly syncs the appointment with Google Calendar.
- AquaMail meanwhile incorrectly shows the core reoccuring appointment, putting it on at the right time but on the following day. Deleted and new/moved app
From a corporate/business perspective there is nothing more frustrating.
Sent from my SM-G920F using Tapatalk
-
In your log I was able to see the data which Aqua Mail stored into the Android calendar. I did not see anything wrong with it.
-
Happy to show you the issue. Pretty clear to me. What details would you require to convince you that this is an issue?
Sent from my SM-G920F using Tapatalk
-
I'm not saying that the issue does not exist.
I'm saying that I've seen your log, looked at actual data that Aqua Mail stored into the Android Calendar and did not see anything wrong with it.
-
I just looked at the log again.
The event's time zone on the server is UTC - and you're in UTC+10. This moves the event to next day.
There is evidence (in the event's description) that the event's sender is aware that UTC is a problem and sends updates "to adjust for seasonal time changes across the offices".
Had the event's time zone on the server been correct (your actual time zone) to begin with -- none of those "adjustments" would have been necessary, it would have just worked.
There is no Aqua Mail bug here.
Garbage in (wrong time zone) -> garbage out.
-
no probs... I'll get the event recreated
Sent from my SM-G920F using Tapatalk
-
I have a similar issue with birthday entries in my Office365 calendar. Some of them are shifted one hour, which could be the UTC offset - I am in Germany.
On the other hand, some are correct. I think, it might be a correlation with the starting date of the series. Older persons are wrong, younger are correct, but I did not find time to check every single date.
Regards, Heiko
PS Anyway I am very happy with AquaMail. I am using the payed version since years.
-
Re: I have a similar issue with birthday entries in my Office365 calendar.
Did you create those as Calendar events -- or are those in your Contacts?
If the former, yes it could be due to the time zone -- but Aqua will store (per event) the time zone returned by the Exchange server. So that's the part that could be wrong.
Anyway, if you'd like to diagnose:
Please enable debug logging (with raw data), change an event's color in web mail or Outlook, then "refresh" in Calendar app. Wait to complete and finally send the log to support / aqua-mail / dot com.
-
I did not create the events, outlook does. I have just entered the date of birth in the contact.
Once I tried to update one of the calendar event series in the Android calendar app, but the earliest possible year was 1970. As this didn't match, I dropped this idea.
I will try to get a log, tomorrow with my company's outlook, as this is my data source.
Regards, Heiko
-
I have sent an email with logs and screen shots.
Thanks for your support.
-
I have sent an email with logs and screen shots.
Thanks for your support.
The wrong date appears to be a server bug, I responded with detailed info.
The other bug that you brought up in your email is now fixed in the 1.11-dev builds.