[ical4j] MS "Bangladesh Standard Time" maps to Asia/Astana instead of Asia/Dhaka

[tbocek]

Hi, I am using devx5 (4.4.1.1-ose) and I recently received a calendar invite that shows the correct time in Thunderbird (event is 09:00 in the morning), but not in my Android phone (it shows event is at 13:00). So my question is what happens if a TZID is found that is not a valid timezone identifier (TZID) as in https://en.wikipedia.org/wiki/List_of_tz_database_time_zones -> DTSTART;TZID=Bangladesh Standard Time:20240808T130000. There is a VTIMEZONE in this calendar entry with this timezone identifier and it seems that Thunderbird is using the VTIMEZONE definition, while davx5 is not. Could that be my issue?

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Bangladesh Standard Time
BEGIN:STANDARD
DTSTART:16010101T000000
TZOFFSETFROM:+0600
TZOFFSETTO:+0600
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T000000
TZOFFSETFROM:+0600
TZOFFSETTO:+0600
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
...
DTSTART;TZID=Bangladesh Standard Time:20240808T130000
DTEND;TZID=Bangladesh Standard Time:20240808T140000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20240806T070936Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:1
LOCATION;LANGUAGE=en-US:Microsoft Teams Meeting
...
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR

[ArnyminerZ]

If the VTIMEZONE is defined correctly, as it seems, having a "non-standard name" should not matter I think, @rfc2822 can confirm.

However, that name is recognized by ical4j and replaced by Asia/Astana:

https://github.com/ical4j/ical4j/blob/develop/src/main/resources/net/fortuna/ical4j/transform/compliance/msTimezoneNames#L74

However, Asia/Astana is defined as UTC+5 (see), as opposed of UTC+6 (see) that Bangladesh is supposed to have (ref). According to that same page, the correct replacement should be Asia/Dhaka and not Asia/Astana. If that's correct, I can create a new PR in ical4j to fix it.

[rfc2822]

Both MS and the Unicode mapping table indicate that Bangladesh Standard Time (MS TZID) maps to:

• Dhaka [MS]
• Asia/Dhaka [Unicode CLDR]

So yes:

So from my limited timezone understanding, it should be replaced by Asia/Dhaka as this timezone exists on Android, and is UTC+6 and not UTC+5 as you pointed out.

I agree.

Oh, and I guess when its replaced by Asia/Astana, it will ignore the VTIMEZONE definition, as the tzid was replaced. Thus, no >timezone in my case.

This indeed seems to be the cause. Can you use another time zone as a workaround?

@ArnyminerZ Can you please check whether this is still present in the latest ical4j (4.x) and report it there?

[tbocek]

@rfc2822, develop and master of ical4j contains Asia/Astana, so I went ahead and create a PR against develop: ical4j/ical4j#718

[tbocek]

This solves my problem, but I think it does not fix the underlying problem. When Outlook creates a calendar entry with e.g., Central Asia Standard Time, which is Asia/Astana, the timezone will be ignored when synced to Android.

I think the steps should be changed to:

1. step: search the timezone in the calendar entry in VTIMEZONE. If that is found, then the offset can be set. done.
2. step: try replace with transform-compliance-msTimezoneNames, then search system tzid, if found done.

I'm not sure about the current order, but I think that now step 2 comes before step 1 (I haven't looked to deep into it, so I could be wrong).

[rfc2822]

When Outlook creates a calendar entry with e.g., Central Asia Standard Time, which is Asia/Astana, the timezone will be ignored when synced to Android.

That's the intention of replacing the MS timezones. We could use the VTIMEZONE, but since the TZID isn't present in Android, we couldn't store the time correctly in Android. It's not only about the offset (then I agree it would be possible), but about the whole set of timezone rules.

As I understand it, ical4j 4.x (currently we use 3.x) also introduces timezone handling changes (namely it consequently uses Java 8 Time API including timezone definitions), so if at all, we should have a look at this as soon as we use ical4j 4.x (which is a very big change, so it will take a while).

[tbocek]

I see, thanks for the insights!

The PR was merged: ical4j/ical4j#718

[rfc2822]

Good. I think it however won't be available for ical4j 3.x. Can you use another timezone as a workaround?

[tbocek]

Yes, I can work around it. Thanks for your help!