Status

Calendar
Calendar Views
P1
major
RESOLVED WORKSFORME
2 years ago
a year ago

People

(Reporter: Joris, Unassigned)

Tracking

({calendar-integration})

Lightning 4.0.5.2
x86_64
Linux
calendar-integration

Details

(Whiteboard: 2016 Leap year issue)

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
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.
(Reporter)

Updated

2 years ago
Severity: normal → major
Keywords: calendar-integration
OS: Unspecified → Linux
Priority: -- → P1
Hardware: Unspecified → x86_64
Whiteboard: 2016 Leap year issue

Comment 1

2 years ago
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.
(Reporter)

Comment 2

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

Comment 3

2 years ago
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.
(Reporter)

Comment 4

2 years ago
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...
(Reporter)

Comment 5

2 years ago
Created attachment 8744332 [details]
Screenshot from 2016-04-22 15:10:24 - TB.png

Screenshot 3 events in TB/Lightning
(Reporter)

Comment 6

2 years ago
Created attachment 8744333 [details]
Screenshot from 2016-04-22 15:11:25 - ZCP.png

Screenshot 3 events in Caldav/ZCP

Comment 7

2 years ago
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?

Comment 8

2 years ago
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.
(Reporter)

Comment 9

2 years ago
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.
Flags: needinfo?(j.leblansch)
(Reporter)

Comment 10

2 years ago
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: 2 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(j.leblansch)
You need to log in before you can comment on or make changes to this bug.