Z-Push with CalDAV backend - timezone issues
I have been trying to get Z-Push running with my Nextcloud system to provide contacts and calendar to my Windows 10 devices. So far, with limited success I may have missed something crucial, since I cannot believe that I am the only person experiencing this issue, but it seems that any calendar entry I make in Nextcloud ends up in the wrong time zone when synced over Z-Push. My setup:
- Ubuntu 16.04 LTS with Nextcloud 11.0.3 from the repo (http://repo.morph027.de/#nextcloud-server)
- Z-Push 2.3.6 from the repo (http://repo.z-hub.io/z-push:/final/Ubuntu_16.04/)
Syncing works fine, but when I create an entry in the Nextcloud web interface (i.e. 10:00 to 10:30), it is synced as 11:00 to 11:30. I observed this with Windows 10 Calendar, Windows 10 Mobile and also eM Client. I first thought it has to do with my time zone settings (Europe/Berlin), but this is configured correctly (server, php.ini, z-push.config, Nextcloud and my clients). Next idea: Nextcloud is doing something weird. I then configured Z-Push to use the CalDAV calendar provided by my Synology Diskstation - and I see the same effect. This seems to suggest it is caused by Z-Push. Next thing I noticed: a calendar entry without daylight savings time (i.e. in February) is synced fine. So, maybe there is some DST issue in Z-Push? I also looked at the logs (WBXML enabled), and it seems that Z-Push does not send a time zone to the client. This seems to make sense, because an entry I create in eM Client is synced correctly. So, I am at a loss here and don’t really know how to continue.
FWIW, I followed these instructions to setup Z-Push with Nextcloud: https://help.nextcloud.com/t/z-push-sync-and-how-it-works/5688
Oh, and to rule out some errors with my Ubuntu installation, I also tried it on an RPi 2 running OSMC (both Nextcloud and Z-Push). Same problem. I also tried the latest dev branch from Git - same problem.
If needed, I can provide my config files and the logs and the CalDAV ics file.
Any help is greatly appreciated!
Normally the CalDav backend should extract the timezone from the ICS file.
Can you provide:
- z-push wbxml log where the appointment is synchronized to the mobile
- the ICS file
Could you try to:
- create a new calendar item on your phone. Is it correctly displayed in NextCould?
- Edit this appointment in NextCloud
- On update to the phone: does it have a timezone definition in the wbxml?
- Is it correctly updated on the phone?
An then, does EM client still have ActiveSync support? My last update was that they wanted to remove it (iirc in version 7?).
Hi Sebastian, thanks for getting back to me so quickly! I did the following:
- Create appointment “Test 1 (on Nextcloud)” using Nextcloud web frontend, 10:00 to 10:30 (see test1.png)
- Sync to eM Client (test1.log, https://pastebin.com/tAFMXvVf) -> appointment shows up as 11:00-11:30
- Create appointment “Test 2 (eM Client)”, 11:00 to 11:30 in eM Client and sync it to Nextcloud (see test2.png and test2.log, https://pastebin.com/3dKhxRh8) -> shows up correctly in Nextcloud - but shows UTC as time zone
- Change name of appointment in Nextcloud to “Test 2 (eM Client, modified)” and sync back to eM Client (test2b.png, test3.log, https://pastebin.com/6arNeN5u) -> shows up correctly in eM Client
- Change time of appointment in Nextcloud (to 10:00-10:30), sync back to eM Client (test4.log, https://pastebin.com/6A9xD1Vb) -> shows up correctly
Thanks so much!
btw, eM Client still supports ActiveSync, albeit only for Outlook.com. After creating an account, it will let you modify the server address
the problem is how the caldav backend tries to determine the timezone from ical data. I’ve created a ticket for this issue: https://jira.z-hub.io/browse/ZP-1224. You can follow the progress there.
thanks for getting into this problem! I just checked out your branch using git and tried it. Unfortunately, to no avail
A calendar entry created at 10am in Nextcloud (time zone Berlin) still syncs as 11am to my Phone (W10M) and to eM Client. The sync log of this single entry is here: https://pastebin.com/HVuUyrt2
I can see that your new function is triggered (line 185) in the log, but it still doesn’t work. The time zone of the calendar entry in eM Client is now totally strange, it looks Chinese:
Thanks so much for looking into my problem, though!
the timezone sent to the eM client looks correct. It results into CET:
[bias] => -60 [tzname] => CET [dstendyear] => 0 [dstendmonth] => 10 [dstendday] => 0 [dstendweek] => 5 [dstendhour] => 1 [dstendminute] => 0 [dstendsecond] => 0 [dstendmillis] => 0 [stdbias] => 0 [tznamedst] => CEST [dststartyear] => 0 [dststartmonth] => 3 [dststartday] => 0 [dststartweek] => 5 [dststarthour] => 1 [dststartminute] => 0 [dststartsecond] => 0 [dststartmillis] => 0 [dstbias] => -60 [timezone] => -60 [timezonedst] => -60
It might be that the eM client doesn’t understand that and expects a different description.
The dststarthour and dstendhour are wrong (should be 2 and 3), so it’s also possible that’s the reason why the eM client doesn’t recognise the timezone correctly.
thanks for being so patient with my problem. I really appreciate this! Unfortunately, I don’t believe it’s eM Client’s fault. I didn’t mention this in my last post, but the behavior with Windows 10 Calendar app (both desktop and mobile) is also wrong. There, the event is synced just as incorrectly. But one thing is quite interesting: an event outside DST syncs properly. To make sure I don’t do anything exceedingly stupid, I also tried Outlook 2013 as a client - the exact same behavior: events with DST are one hour off (i.e. 10am instead of 9am) and events outside DST sync fine. I also observed that eM Client also does not properly decode the time zone for non-DST events, showing the same strange Chinese (?) character.
I’ve changed the caldav backend to use the Z-Push timezone functions which are also used by other backends. Please try the branch again.
unfortunately, no change. An appointment at 11am CEST still shows up as 12 noon. Same in eM Client, Windows 10 Calendar (both desktop and mobile) and Outlook 2013.
Log file: https://pastebin.com/BfqCGGfq
the timezone information is correct, but it looks like that caldav backend doesn’t correctly handle the daylight saving bias.
09/06/2017 15:58:14 [ 2191] [WBXML] [robby_hl] O <POOMCAL:StartTime> 09/06/2017 15:58:14 [ 2191] [WBXML] [robby_hl] O 20170610T100000Z 09/06/2017 15:58:14 [ 2191] [WBXML] [robby_hl] O </POOMCAL:StartTime>
It should be 20170610T090000Z.
I’ve created another ticket for this: https://jira.z-hub.io/browse/ZP-1236.