Calendar Entries - Scheduled Time One Hour Later Than Set

Bug Reports
,
#26

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
#27

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…

Screenshot_20210719_005
Screenshot_20210719_0051080×1920 508 KB

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) …

Screenshot_20210719_004
Screenshot_20210719_0041080×1920 474 KB

And here’s what the same event looks like on the iPhone …

979d42c88342619d77682c4f9ec305ab33ae879f
979d42c88342619d77682c4f9ec305ab33ae879f295×640 149 KB

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.

#28

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.

  1. 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?

  2. 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.

  3. 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?

#29

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
#30

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.

#31

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.

[Release notes] Vanha Rauma 4.4.0.64
#32

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.

#33

See also this discussion from late 2005!

#34

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 DTSTART at day D and a DTEND at 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 and event->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…

#35

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?

#36

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!!! :rofl:

1 Like
#37

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”.

#38

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.

#39

@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?

#40

@Steve_Everett, can I please ask, are you’re still experiencing this issue?

#41

@flypig Yes, and No. Because of all the issues are with synchronisation of Exchange (Office365) accounts, specifically (and all of which I’ve previously reported as bugs):

  • Accounts fail to sync with errors when network changes from mobile to wireless and vice versa
  • Email auto synchronise just completely stops randomly with no more auto sync until you re-boot
  • Not all email folders are shown, so if I have say 30 email folders on my Exchange accounts, then only 20 of them, seemingly at random, get shown and can be used/accessed when you swipe left to the folder view
  • Calendar issues (i.e. dates later than they should be, all day events spilling over into the next day when they should not be, etc)
  • Contact issues (favourites disappear, duplicates, etc)

I decided I’d had enough as it was just not usable or reliable enough. So all of the above are still happening on XA2 on 4.3 as of last week.

However, having found that Office 365 also supports imap synchronisation I have, last weekend, changed all my Office 365 accounts from Exchange Sync to IMAP sync.

But since Office 365 does not support caldav or carddav I have had to make some other changes as I need both calendar and contacts - and obviously moving from Exchange sync to IMAP sync I have now lost the ability to synchronise my calendar and contacts with Office365. So:

  • I have moved my calendars to my home NAS server (Synology) and now sync calendars with this across all my devices using caldav.
  • I have moved my contacts onto the synology NAS server, but I can’t yet get carddav to work with this. This is probably due to not getting the syntax right on the carddav account on SFOS as it doesn’t seem to be standard across ios, android, windows, linux, etc. And SFOS seems to have a weird combined carddav/caldav account layout which I can’t quite work out yet (eg: if I set the port on the server for caldav, then its not right for carddav and vice versa). So the upshot at the moment is that I have moved all my contacts locally onto SFOS until I can figure carddav out.

The result of all these changes are:

  • IMAP email sync to Office 365 works just fine - no missing folders, no sync errors, auto sync does not fail or stop. In short it works reliably and well.
  • Calendar sync to my NAS server also works reliably and well - entries are at the right time and not one hour late, all day entries are scheduled only for the days they are meant to be, not those days +1
  • Contact favourites work and persist as they should with no duplicates (well obviously, because they are static and not sync’d).

So all is good and the problems have all been ‘resolved’ by these changes - even if it was all a bit of a pain to make them.

Seems to me that the inescapable conclusion, and perhaps why so few forum members have these bugs (because it appears that Exchange is not widely used), is that pretty much all of the above problems come from bugs in the Exchange sync plugin code?

#42

Just as a side note, the time zone on the synology NAS is ‘United Kingdom, London’ - the same as my SFOS XA2.

#43

Also see IMAP Email Setup Bugs on 4.3 as one of the setup issues I had when specifying a peak synchronisation time range for the IMAP email account to Office365 was that, yes, you’ve guessed it, the time range ended up being an hour later than I set it.

#44

So just to clarify this point, as of a couple of weeks ago before you switched to CalDAV, and using 4.3 Suomenlinna, you still experienced Exchange events moving by an hour as a result of a sync?

I want to separate this from all day events spilling over into the next day (which I’m looking into separately). I appreciate it’s tempting to bundle all of the issues together, but when it comes to fixing them, it’s really helpful to keep things isolated.

#45
1 Like