How to deal with obsolete timezones

[Peter Menhart]

Hi Mike,

A suggestion to improve robustness of timezone handling, based on your wiki http://sourceforge.net/p/biweekly/wiki/Working%20with%20Timezones/.

For example, "PRC" is not a IANA timezone (yet supported as a valid timezone in Linux). TzUrlDotOrgGenerator lookup via http://tzurl.org/zoneinfo-outlook/PRC will return "Asia/Shanghai" instead. As a consequence, VCALENDAR will have references to non-existent TZID=PRC, and corrent (but unused) VTIMEZONE element "Asia/Shanghai":

BEGIN:VEVENT
DTSTART;TZID=PRC:20150820T140000
DTEND;TZID=PRC:20150820T140000
...
BEGIN:VTIMEZONE
TZID:Asia/Shanghai

Some calendar clients can find "an approximate replacement" (Outlook), some may warn about "unknown timezone error" (Thunderbird), and use wrong offset.
My workaround: compare original tz.ID with the value retrieved from tzurl.org in generate(). If they differ, then use the new timezone:

:::Java
        // (true): Use Outlook-friendly VTIMEZONE components. (false): use default iCalendar definitions
        VTimezoneGenerator tzGenerator = new TzUrlDotOrgGenerator(true);
        String newTzId = tzGenerator.generate(tz).getTimezoneId().getValue();
        if (!tz.getID().equals(newTzId)) {
            // tz is not a standard timezone, and calendar clients may not recognize it.
            tz = TimeZone.getTimeZone(newTzId);
        }
        icalWriter.getTimezoneInfo().setGenerator(tzGenerator);
        icalWriter.getTimezoneInfo().setDefaultTimeZone(tz);

I guess it could be useful to mention this problem in the wiki. Even better, incorporate an automatic fix to the library?

Thanks
Peter

[Michael Angstadt]

Peter,

Thank you for pointing this out. If the value of a property's TZID parameter is different than the value of the timezone's TZID property, then that's a big problem. I will look into this.

I created a ticket for this: https://sourceforge.net/p/biweekly/tickets/11/

[Michael Angstadt]

Hi Peter,

It should be fixed now. Thanks again for pointing that out.