Windows timezone not parsed correctly

[slowcar]

Windows timezone not parsed correctly

[slowcar]

On further inspection, i think i found the issue.
The timezone in the ics is "W. Europe Standard Time", which is parsed by biweekly to a timezone with the id "W. Europe Standard Time" and the displayname "GMT+01:00", which is not the same as the Microsoft timezone with the id "W. Europe Standard Time" which would be the olson id "Europe/Amsterdam".

The parsed timezone "GMT+01:00" has an offset of 7200000 (2h) while the "Europe/Amsterdam" timezone has an offset of 3600000 (1h) for the timestamp in question (start of the ics on November 23, 1669190400000 )

The source of the mapping i use is https://github.com/unicode-org/cldr/blob/main/common/supplemental/windowsZones.xml
with code similar to this old snippet https://gist.github.com/scottmac/655675e9b4d4913c539c
or this code https://github.com/LinkedInAttic/RookBoom/blob/master/ews/src/main/java/com/microsoft/exchange/utils/WindowsZonesMapping.java

I built a workaround by using the id of the biweekly timezone as an Exchange identifier and look up the matching olson timezone.

[slowcar]

Looks like it was my mistake, i assumed that vEvent.getDateEnd().getValue() returned a Date with an UTC timestamp, but on further inspection i saw that there are other components in the extended class ICalDate.
Using vEvent.getDateStart().getValue().getRawComponents().toDate(TimeZone.getDefault()) i can get the timestamp

[mangstadt]

Not sure if this helps, but:

In order to parse the "W. Europe Standard Time" timestamps in your examples, biweekly uses the timezone definition data located between the BEGIN:VTIMEZONE and END:VTIMEZONE lines.

If the "TZID" parameter value begins with a /, then biweekly will treat the timezone as an Olsen ID and will use Java's embedded timezone definition to parse the timestamp. For example: DTSTART;TZID="/Europe/Amsterdam":20221029T080000

[slowcar]

The timezone in the ics switches from +0200 to +0100 at the last sunday of october (BYDAY=-1SU;BYMONTH=10), but the parsed timezone does not.

Microsoft does not use Olson ids, which should not matter if biweekly parses the timezone information.

[mangstadt]

Could you write a unit test that demonstrates this?