(fix) Start/end shifting by 1 hour due to timezone change on last Sun…

…day of October 2015 (#3344)
Alinto · Sep 14, 2015 · 6dc02ab · 6dc02ab
1 parent f70876a
commit 6dc02ab
Show file tree

Hide file tree

Showing 2 changed files with 37 additions and 4 deletions.
diff --git a/NEWS b/NEWS
@@ -17,6 +17,7 @@ Bug fixes
  - Support attachments from more mail clients (Zentyal)
  - Avoid conflicting message on saving a draft mail (Zentyal)
  - Less conflicting messages in Outlook while moving messages between folders (Zentyal)
+ - Start/end shifting by 1 hour due to timezone change on last Sunday of October 2015 (#3344)
 
 2.3.1 (2015-07-23)
 ------------------

diff --git a/SOPE/NGCards/iCalTimeZonePeriod.m b/SOPE/NGCards/iCalTimeZonePeriod.m
@@ -161,8 +161,11 @@ - (NSCalendarDate *) _occurrenceForDate: (NSCalendarDate *) refDate
                                   minute: [tzStart minuteOfHour] second: 0
                                 timeZone: [NSTimeZone timeZoneWithName: @"GMT"]];
 
-  tmpDate = [tmpDate addYear: 0 month: ((pos > 0) ? 0 : 1)
-                         day: 0 hour: 0 minute: 0
+  tmpDate = [tmpDate addYear: 0
+                       month: ((pos > 0) ? 0 : 1)
+                         day: 0
+                        hour: 0
+                      minute: 0
                       second: 0];
 
   /* If the day of the time change is "-XSU", we need to determine whether the
@@ -197,12 +200,41 @@ - (NSCalendarDate *) _occurrenceForDate: (NSCalendarDate *) refDate
      END:STANDARD
      END:VTIMEZONE
      
-     The time changes occure on a Sunday, but in March, the 1st is a Sunday itself and in November
+     The time changes occur on a Sunday, but in March, the 1st is a Sunday itself and in November
      the 1st is also a Sunday. If we don't decrement "pos" by one, tmpDate (which is set to March or November 1st
      because of "day: 1" will have 14 more days added for March and 7 more days added for November - which will
      effectively shift the time change by a whole week.
+
+     In Europe/Berlin, we have a different use-case for November. In 2015, November 1st is a Sunday.
+     The time change in November must occur on October 25th but since tmpDate will be November 1st,
+     so a Sunday, dateDayOfWeek will be 0 and dayOfWeek will also be 0 we would decrement tmpDate by 14 days,
+     which is incorrect because it would shift the timezone change one week earlier. We take care about this
+     one with check if pos is greater or equal than 0 and if so, we don't decrement it.
+
+     BEGIN:VCALENDAR
+     PRODID:-//Inverse inc.//NONSGML Olson 2014g//EN
+     VERSION:2.0
+     BEGIN:VTIMEZONE
+     TZID:Europe/Berlin
+     X-LIC-LOCATION:Europe/Berlin
+     BEGIN:DAYLIGHT
+     TZOFFSETFROM:+0100
+     TZOFFSETTO:+0200
+     TZNAME:CEST
+     DTSTART:19700329T020000
+     RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
+     END:DAYLIGHT
+     BEGIN:STANDARD
+     TZOFFSETFROM:+0200
+     TZOFFSETTO:+0100
+     TZNAME:CET
+     DTSTART:19701025T030000
+     RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
+     END:STANDARD
+     END:VTIMEZONE
+     END:VCALENDAR
   */
-  if (dayOfWeek == dateDayOfWeek)
+  if (dayOfWeek == dateDayOfWeek && pos >= 0)
     pos--;
 
   offset = (dayOfWeek - dateDayOfWeek) + (pos * 7);