No, all my other synced devices display the correct time for the event. Its only the Sailfish device that is an hour out. But checking the iPhone settings, this is also set to ‘London’ timezone (which would just be a different label for United Kingdom as we don’t have multiple in-country timezones like the US or Australia). Unfortunately on the iPhone you can’t seem to either see or set the timezone for an individual calendar entry, so I assume it just uses whatever timezone is set in the phone settings.
Just done a bit of googling, from microsoft support docs:
In Office 365, the date and time is based on the time zone setting of the Exchange Online server. Because Office 365 is a cloud service, and users can be in any one of 24 different time zones, the time stamp uses Coordinated Universal Time ( UTC ).
So it would seem that Office365, understandably, runs everything in UTC and perhaps leaves it up to the synchronising devices to translate that into whatever timezone their user is currently in? So it could be that the Sailfish Activesync bit is not making that final translation from UTC to local timezone for whatever reason?
Since the event can contain information about source time zone, requiring client-side translation sounds quite odd.
Not providing translations is another matter…
Although stranger things have definitely happened. (But surely more people would have the issue?)
Another possibility is that the server is using some way of (not?) representing the BST/London timezone which is mistakenly mapped to UTC when it comes back.
Well, there are a few others who have reported the same or similar issue (e.g. @deloptes ) but not many. Though of course its quite conceivable that lots of people would have the issue if they used Office365 Exchange, but because they don’t they never see it. Who knows?
I don’t know anything about calendar entries, but when I was a software development engineer long ago I worked on the X400 email standard and its implementation in security hardened UNIX installations (based on, if memory serves, the Berkley BSD 4.2 version) for the British Ministry Of Defence. This was one of the first secure UNIX systems to use ACLs (Access Control Lists - basically the permissions of today) and secure containers to run processes and manage files at the various security levels (Top Secret, Secret, Classified, Restricted and Unclassified). Here the X400 mail headers always had the timezone of the email sent date/time, receipt date/time, etc and it was the job of the mail client software to display the header timezone in the local timezone for the user. Maybe something similar happens today.
Mucking around a bit more, if I leave the Sailfish entry in UTC but then edit the actual time of the entry to be an hour earlier (and therefore correctly for what I originally wanted it to be), then after it has synchronised with the server and then on to the other devices, those other devices now show the incorrect time (an hour earlier) - and this was probably what I was doing to “correct” this problem when I first encountered and reported it (I’m afraid it never occurred to me to go back in and change the timezone in the calendar entry itself after I had created the entry). This is probably what is supposed to happen but very confusing nontheless!
This is probably what is supposed to happen but very confusing nontheless!
Well, I still think there is a bug on sync from the detailled steps above. There is one unique time for the event with various representations as you said. The event when coming back to Sailfish should show 14.00 UTC is the detailed steps above and you tell me that it is displaying 15.00 UTC, which is inaccurate.
From what you report, I think the bug happens only when you send to the server an event that is in a different time zone than the server. Then when the event comes back to the device, the actual time zone is mis-interpreted and the calendar default time zone is used. That would explain that the majority doesn’t have the problem. You may also try to create on device an event specifying UTC as the time zone. If I’m right it should propagate to various devices with the right time and comes back to Sailfish also in a proper way.
Or another possibility is that server in UTC is not properly handled by Sailfish and that is a rare case ?
1 Like
I tried this. So here’s the event on Sailfish - I set the time from 10 pm until 11:00 pm. I couldn’t select UTC as a timezone from the list but it was ‘on top’ as you said in a previous post…
and here’s how it then looks in the normal calendar view after synchronisation. Its obviously displaying it in UK time (which is probably right even though it looks an hour late) …
And here’s what the same event looks like on the iPhone …
So it looks like the iPhone has also converted UTC to UK and added an hour as a result. Both are consistent and I think that this is working correctly - So I believe you are right.
OK, So a summary of the situation…
Office 365 Exchange Servers operate in the UTC ‘Timezone’.
Sailfish phones normally operate in a local time timezone.
-
If you create an event on Sailfish in a local timezone, following synchronisation with Office365 it gets reflected back in UTC. There is then a conflict which Sailfish doesn’t handle correctly and it assumes what it is getting back is in the same timezone that the phone is set to - so the calendar displays the entry late (in my case the difference is one hour between UTC and the current UK timezone, but it may be more for others. In BB10 you could decide when a sync conflict occurred to give priority to the server version or the device version. Perhaps in Sailfish its always the server version as there is no option?
-
If the event is created outside of Sailfish (e.g. on another synced device or received via a calendar invite) then this is also received in UTC and the same problem occurs.
-
If the event is deliberately created on Sailfish in UTC, rather that the timezone the phone is set to, it gets reflected back from the server in UTC, no conflict occurs and everything synchronises correctly across all devices.
Does this sound reasonable?
I wonder what would happen if you synced with an Exchange server which wasn’t an Office365 cloud based server operating in UTC, but was set to run in the same local timezone that the phone was set to. Would it all work correctly then?
Thanks for the really detailed analysis here, which I have to say is incredibly helpful. I think you’ve managed to narrow down the bug quite carefully. I’ve lodged an internal issue on our bug tracker, and while I can’t say when it’ll be possible for someone to look at this, hopefully it’ll be soon as I can see it’s a problem.
As @dcaliste points out, the bug seems to be in an internal components, so I won’t be able to post links to any PRs here, but I will do my best to post updates if there’s anything to mention, or if any queries arise.
2 Likes
The office 365 server used by my organization operates in local time. I have no time shift when I create an event with a start and end time on my Sailfish XA2 and synchronize it with office365.
However, for all day events created in office365, they expand over the next day in Sailfish calendar and if I check in Outlook they run from the day 00h00 to the folowing day 00h00.
Yes, I have the same problem with all-day events spilling over into the next day (so a one day all-day event is shown incorrectly as an all-day event for two days).
I had assumed, maybe wrongly, that this was the same, or similar problem, as the issue above, but maybe it’s not.
Technically I suppose an event that runs from midnight to midnight is a two day event (by one minute) and therefore Sailfish is correct to display it as such.
However if this is the accepted practice for representing an all-day event by everybody else then it probably makes sense for Sailfish to recognise this, ignore the single minute overspill and show it as a single all-day event.
At least then the synchronisation would work for this type of event.
Here my TDE creates whole day event with following
DTSTART;VALUE=DATE:20210722
DTEND;VALUE=DATE:20210723
and complies to the information provided here
IMO the best would be to export or send the event, so one could see how it is defined in Sailfish.
See also this discussion from late 2005!
The problem is that we don’t have access to the code of the Exchange plugin so we don’t know what it is doing to convert the iCal format into the internal format used by KCalendarCore and mKCal.
What is sure is that :
- iCal defines duration in an exclusive way, so an event with a
DTSTARTat day D and aDTENDat D+2 is a two days long event finishing at the end of day D+1. - KCalendarCore and mKCal are using the opposite convention, they are inclusive.
event->dtStart()at D andevent->dtEnd()at D+1 is an event two days long finishing at the end of D+1.
Normally, using the KCalendarCore::ICalFormat handle this transparently, so reading an iCal serialisation is setting the dtEnd with the right convention.
But mKCal has been broken with respect of this in the past and was not restoring the full day events properly (it mixed up the KCalendarCore and the iCal format conventions). This bug has been solved some years ago, but maybe the workaround in the Exchange plugin has not been removed, creating this bug… No idea once again, depends on sources…
Unfortunately it is a mess. But the fact that the “Standard” is not inclusive and KCalendarCore is inclusive does not mean it is wrong. The convention would be to convert the ical into the proper representation in KCalendarCore and v.v. but you are right that we do not know what the EAS plugin is doing. For me it stopped working long time ago. AFAIK the EAS was in the licensed part, or am I wrong?
If your question is whether Exchange Synchronisation is part of the paid license for Sailfish X, then yes.
In any case I have just booked my holiday and find that Sailfish has given me an extra day, so maybe we’d better leave things!!! 
1 Like
I have my Xperia 10 II (running the upcoming 4.2.0 release) in the Finnish (EET) local timezone. The calendar entries in my Jolla Exchange calendar, be they created on Xperia or using the Outlook web access, appear at the correct times also after syncing the calendar. I created the events using the Finnish timezone. I have “Automatic update” enabled in “Settings > Time and date”, so this should handle the summertime, too.
In fact, Sailfish has this option. At the end of the settings of Exchange accounts, there are “Advanced settings” which contain the item “Resolve conflicts” with options “Priority to server” (default) and “Priority to device”.
If I may, the problem is occurring when on the server, the calendar is setup to use a UTC time zone. What about the configuration of your server ?
I cannot reproduce personnaly because I’ve no access to an exchange server, so these are information that may not be exact neither to reproduce the bug.
@jovirkku Perhaps one way of you hopefully seeing the problem for yourself is for you to send me an email (steve.everett’at’vale-anderson.com) from your outlook account. I will then send you a couple of calendar entries from my phone (one all day entry and one timed entry) to your email address in your Finnish timezone. This will then obviously go through my Office 365 Exchange server before ending up on your Sailfish phone. OK, its not the same as creating and looking at the event on the same Sailfish phone, but at least it will be synchronising via an Office365 server running on UTC so it might show up the problem?