Timezone not working if date is in the future and after a daylight saving switch

[InteractiveScape]

Timezone not working if date is in the future and after a daylight saving switch

[mangstadt]

The fix you described doesn't work for me. Is this what you did?

if ((after && comparison <= 0) || comparison < 0) {
	RecurrenceIterator it = createIterator(observance);

	/*
	 * The "advanceTo()" method skips all dates that are less than the
	 * given date. I would have thought that we would have to call
	 * "next()" once because we want it to skip the date that is equal
	 * to the "last" date. But this causes all the unit tests to fail,
	 * so I guess not.
	 */
	//it.advanceTo(last); //REMOVED
	//it.next();

	DateValue prev = null, cur = null;
	boolean stopped = false;
	while (it.hasNext()) {
		cur = it.next();
		if (cur.compareTo(last) <= 0) continue; //ADDED
		dateCache.add(cur);

		if (givenDate.compareTo(cur) < 0) {
			//stop if we have passed the givenTime
			stopped = true;
			break;
		}

		prev = cur;
	}
	return after ? (stopped ? cur : null) : prev;
}

[InteractiveScape]

I just realized that in my production code I used if (cur.compareTo(last) < 0) continue; without the =.
However that would add a duplicate to the cache when cur.compareTo(last) == 0. That's why I added the = without further testing however the breaking condition afterwards is important.

That's my current working version:

DateValue prev = null, cur = null;
boolean stopped = false;
while (it.hasNext()) {
    cur = it.next();
    int curComparison = cur.compareTo(last);
    if (curComparison < 0) continue;

    if (curComparison > 0) {
        dateCache.add(cur);
    }
				
    if (givenDate.compareTo(cur) < 0) {
        //stop if we have passed the givenTime
        stopped = true;
        break;
    }

    prev = cur;
}
return after ? (stopped ? cur : null) : prev;

[mangstadt]

I keep getting 8:30 for the start time instead of 9:30. Do you see anything wrong with this unit test?

@Test
public void test() throws Exception {
	ICalendar ical = Biweekly.parse(getClass().getResourceAsStream("issue126.ics")).first();
	VEvent event = ical.getEvents().get(0);

	/*
	 * The event dates come after the last Sunday in October, so they should
	 * be in standard time (offset of +01:00).
	 */

	Date expected = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss Z").parse("2023-11-22 09:30:00 +0100");
	Date actual = event.getDateStart().getValue();
	assertEquals(expected, actual); //FAILS -- the time is 8:30, not 9:30

	expected = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss Z").parse("2023-11-22 12:00:00 +0100");
	actual = event.getDateEnd().getValue();
	assertEquals(expected, actual);
}

[InteractiveScape]

No, the unit test looks good and works for me together with my above changes to ICalTimeZone.

[M66B]

The same problem, the parsed time being one hour too early, occurs in this ics file:

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:GMT Standard Time
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T010000
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=OrganiserName
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=rcpt
DESCRIPTION;LANGUAGE=en-GB:BLAHBLAHBLAH
UID:xxxxxxxxxxxxxx
 xxxxxxxxxx
SUMMARY;LANGUAGE=en-GB:Meeting Title
DTSTART;TZID=GMT:20231030T103000
DTEND;TZID=GMT:20231030T110000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20231027T114207Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-GB:Microsoft Teams Meeting
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:xxxxxx
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-ONLINEMEETINGINFORMATION:xxxxxxx
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-REQUESTEDATTENDANCEMODE:DEFAULT
X-MICROSOFT-LOCATIONDISPLAYNAME:Microsoft Teams Meeting
X-MICROSOFT-LOCATIONSOURCE:None
X-MICROSOFT-LOCATIONS:[{"DisplayName":"Microsoft Teams Meeting"\,"LocationA
 nnotation":""\,"LocationUri":""\,"LocationStreet":""\,"LocationCity":""\,"
 LocationState":""\,"LocationCountry":""\,"LocationPostalCode":""\,"Locatio
 nFullAddress":""}]
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR

[M66B]

Applying this patch resolves the issue:

#126 (comment)

[mangstadt]

@M66B Your example cannot be used to test this issue. The start/end dates of the event do not make use of the VTIMEZONE definition. Their TZID parameter is set to "GMT", which does not match the TZID value of the VTIMEZONE definition.

[M66B]

Still, the proposed changes result in a correct even start and end time.

[mangstadt]

My unit test is working now. I might have forgotten to remove the it.advanceTo() line.

Patch has been merged. Thanks for your work @InteractiveScape!