User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160413222640 Steps to reproduce: Make a calendar entry on or after 28/03/2016 while ticking "all day event". Actual results: When saving this all-day event on 28/03 it actually displays on 27/03 one day earlier. When opening the underlying caldav calendar though, the entry is correctly saved on 28/03. Expected results: It should have just displayed on the 28th of course where the real entry also is. Apparently the leap year of 2016 is not taken into consideration and exactly 4 weeks after the 29th of February the issue starts. This issue then continues to occur for any future date.
Severity: normal → major
OS: Unspecified → Linux
Priority: -- → P1
Hardware: Unspecified → x86_64
Whiteboard: 2016 Leap year issue
This works for me with a local calendar with a non recurring event. Can you please attach the event? What calendar do you use? If it is a network calendar, please enable calendar.debug.log and calendar.debug.log.verbose, clear the error console, reproduce the issue and post here the messages you get in the error console. If you want to hide some information for privacy reasons, please make sure to not change the data structure.
Indeed it does work with a local calendar. I'm using a caldav calendar though. I have enabled the debug log and have the following entries when reproducing the issue : ------ Timestamp: 22/04/2016 12:16:55 Warning: Use of getPreventDefault() is deprecated. Use defaultPrevented instead. Source File: chrome://calendar/content/calendar-event-dialog.xul Line: 0 ------ CalDAV: itemUri.spec = https://mail.[domainname].fr:8443/caldav/[username]/calendar/a00460a1-a7af-4d94-bc91-65f8433651ce.ics ------ CalDAV: send: BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VEVENT CREATED:20160422T101654Z LAST-MODIFIED:20160422T101702Z DTSTAMP:20160422T101702Z UID:a00460a1-a7af-4d94-bc91-65f8433651ce SUMMARY:Test 28/03 DTSTART;VALUE=DATE:20160328 DTEND;VALUE=DATE:20160329 TRANSP:TRANSPARENT END:VEVENT END:VCALENDAR ------ CalDAV: recv: ------ CalDAV: Item added to [username] successfully ------ CalDAV: send(https://mail.[domainname].fr:8443/caldav/[username]/calendar/): <?xml version="1.0" encoding="UTF-8"?> <C:calendar-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><D:getetag/><C:calendar-data/></D:prop><D:href>/caldav/[username]/calendar/a00460a1-a7af-4d94-bc91-65f8433651ce.ics</D:href></C:calendar-multiget> ------ CalDAV: recv: <C:multistatus> <C:response> <C:href>/caldav/[username]/calendar/a00460a1-a7af-4d94-bc91-65f8433651ce.ics</C:href> <C:propstat> <C:prop> <C:getetag>1461320310</C:getetag> <D:calendar-data>BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Zarafa//7.2.1-51838//EN CALSCALE:GREGORIAN METHOD:PUBLISH BEGIN:VTIMEZONE TZID:Europe/Amsterdam BEGIN:STANDARD DTSTART:19700101T000000 TZOFFSETFROM:+0100 TZOFFSETTO:+0100 END:STANDARD END:VTIMEZONE BEGIN:VEVENT TRANSP:TRANSPARENT X-MICROSOFT-CDO-INTENDEDSTATUS:FREE CREATED:20160422T101830Z LAST-MODIFIED:20160422T101830Z DTSTAMP:20160422T101830Z DTSTART;VALUE=DATE:20160327 DTEND;VALUE=DATE:20160328 SUMMARY:Test 28/03 CLASS:PUBLIC UID:a00460a1-a7af-4d94-bc91-65f8433651ce X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20160422T101831Z X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20160422T101831Z X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-OWNERAPPTID:-1 X-MICROSOFT-CDO-ALLDAYEVENT:TRUE END:VEVENT END:VCALENDAR </D:calendar-data> </C:prop> <C:status>HTTP/1.1 200 OK</C:status> </C:propstat> </C:response> </C:multistatus> ------ aChangeLogListener=undefined calendarURI=https://mail.[domainname].fr:8443/caldav/[username]/calendar/ iscached=true this.mQueuedQueries.length=0 ------ It seems to get posted right but then the dates changes -1 day. I don't see though at which moment this happens exactly...
This is changed on the serverside, so Lightning is working correctly. But maybe it's enough to configure your timezone in Lightning if you haven't done that so far to get evetything to play nicely together. Otherwise, please check your server configuration, especially the timezone related one and/or report a bug with your caldav server. For the latter, consider to add a reference here.
Unfortunately it is not as simple as that and timezones were already correctly configured. Client as Europe/Paris and server as Europe/Amsterdam which is strictly the same. I also tried putting both to Europe/Paris with same results. Here's some more scenarios : - make test entry "Test 28 TB/Lightning" for 28/03 all day directly in TB : upon saving event jumps to 27/03 in TB/Lightning view. - make test entry "Test from WebApp" for 28/03 all day directly on caldav server (Zarafa ZCP 7.2.1) : upon saving event shows correctly on 28/03 in WebApp view. - make test entry "Test Mobile" for 28/03 all day on attached mobile device synching it's changes through z-push to the caldav server : upon saving event shows correctly on 28/03 in mobile and WebApp view. - Looking back at the TB/Lightning view all 3 entries show incorrectly on the 27th. - Looking back at the WebApp view of the caldav server or an attached mobile phone all 3 entries show correctly on the 28th. See attached screenshots. Bearing this in mind how can it not be a Lightning issue ? The server and it's other clients do work as expected and correctly...
Created attachment 8744332 [details] Screenshot from 2016-04-22 15:10:24 - TB.png Screenshot 3 events in TB/Lightning
Created attachment 8744333 [details] Screenshot from 2016-04-22 15:11:25 - ZCP.png Screenshot 3 events in Caldav/ZCP
Hi joris, looking at the log it seems pretty clear a change made by the server. Since the 27th of March the DST changed occurred, I tried to google a bit and I've found this: https://forums.zarafa.com/showthread.php?11139-zarafa-ical-Issues-with-daylight-savings that seems a very similar issue even though it has been declared fixed the 25/1/2016. Maybe can you investigate more about Zarafa versions (and related apps/webapps) and possible issues caused by DST?
Lightning sends the all-day event with 20160328 to the Zarafa server: > CalDAV: send: BEGIN:VCALENDAR > ... > DTSTART;VALUE=DATE:20160328 > DTEND;VALUE=DATE:20160329 and receives back a all-day event on 20160327 from the Zarafa server: > CalDAV: recv: > ... > DTSTART;VALUE=DATE:20160327 > DTEND;VALUE=DATE:20160328 The post mentioned by Decathlon in comment 7 links to > https://jira.zarafa.com/browse/ZCP-12962 DST - all day events created after the DST shift moved to a day earlier that shows "Fix Version/s: 7.2.2" but the log from comment 2 shows "PRODID:-//Zarafa//7.2.1-51838//EN". I think you need to wait until your server is upgraded to at least 7.2.2.
Indeed that seems to point in the right direction. I will endeavour to get ZCP upgraded to 7.2.2 and post back my results asap.
Thanks for having pointed me in that direction Stefan, I have ZCP now at current level 7.2.3 and the issue does not occur anymore, so that is confirmed solved in that way. Hopefully it might help some of you experiencing this issue.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.