1610400 - calendar is having problems with time zones

Status: RESOLVED FIXED

(Calendar :: Lightning Only, defect)

Description

[Guy K. Kloss]

Attachment: empty calendar event/item view dialogue

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

Accepted a calendar invite (iCal format, as base64 encoded MIME email attachment). The invite contains date/times with time zones, example:

DTSTART;TZID="(UTC+12:00) Auckland, Wellington":20200121T120000
DTEND;TZID="(UTC+12:00) Auckland, Wellington":20200121T130000

Then I viewed this specific calendar entry (e.g. in the week view)

Actual results:

When viewing the calendar item, details of the invite are not visible (e.g. description, attendees, etc.).

The Error Console shows this exception:

RangeError: invalid time zone in DateTimeFormat(): (UTC+12:00) Auckland, Wellington mozIntl.jsm:841:9
NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "invalid time zone in DateTimeFormat(): (UTC+12:00) Auckland, Wellington" {file: "resource://gre/modules/mozIntl.jsm" line: 841}]'[JavaScript Error: "invalid time zone in DateTimeFormat(): (UTC+12:00) Auckland, Wellington" {file: "resource://gre/modules/mozIntl.jsm" line: 841}]' when calling method: [calIDateTimeFormatter::formatDateTime] calendar-item-bindings.js:72
    set item chrome://calendar/content/calendar-item-bindings.js:72
    onLoad chrome://calendar/content/calendar-summary-dialog.js:96
    onload chrome://calendar/content/calendar-summary-dialog.xul:1

Expected results:

The proper invite details should be rendered in the event view pop up as expected. As well as they (some of them) are shown in the mouse over hover window.

Comment 1

[Geoff Lankow (:darktrojan)]

Can you attach the whole ical file? Change any personal info if you feel the need.

What I can tell you is that that is an unusual format for the timezone ID (I don't think I've seen it before) and it's also wrong. Auckland and Wellington are UTC+13 on those dates (okay you probably know that, and it's just a label). Where did it come from?

Comment 2

[Guy K. Kloss]

Attachment: sample iCal file from Amazon WorkMail

Attached the sample as it was generated by Amazon WorkMail's calendar, only changed personal details.

```

Comment 3

[Guy K. Kloss]

Attached the sample as it was generated by Amazon WorkMail's calendar, only changed personal details.

When received by email, it is attached as a MIME attachment in base64 encoding, in case that makes a difference.

--=_Knc93NEfSaEqXGTGZHE1bwKzKE2938jjSbC3WhMwnmKC1ONl
Content-Type: text/calendar; method=REQUEST; charset=utf-8
Content-Transfer-Encoding: base64

Comment 4

[Geoff Lankow (:darktrojan)]

Attachment: 1610400-timezone-fail-1.diff

The function in question only appears to like IANA timezone names (Pacific/Auckland) but there's no good way of knowing if any particular string is a valid timezone name. Next best thing is just to try, and do something else if we fail, I guess.

Comment 5

[Guy K. Kloss]

I suppose any treatment but letting the exception go "untreated" is good. But if (as in this case) a substring matching a regex (untested) in the likes of UTC([+-])[0-9]{2}:[0-9]{2} appears, it may be suitable to use that for a fallback treatment.

Somehow, the calendar is doing "The Right Thing" (TM) already as it's diarising the event correctly. So I guess it's just this part of the UI that's having the issue with the time zone.

Cheers for drilling into the issue so promptly!!!

Comment 6

[Magnus Melin [:mkmelin]]

Comment on attachment 9121959 [details] [diff] [review]
1610400-timezone-fail-1.diff

Review of attachment 9121959 [details] [diff] [review]:
-----------------------------------------------------------------

::: calendar/base/src/calDateTimeFormatter.js
@@ +70,5 @@
>        aOptions.timeZone = timezone.tzid;
> +      try {
> +        formatter = new Services.intl.DateTimeFormat(undefined, aOptions);
> +      } catch (ex) {
> +        cal.WARN(ex);

if this throws, formatter won't be usable below. 
return null here, or what?

Comment 7

[Geoff Lankow (:darktrojan)]

If it throws, formatter will have the same value it already had.

Comment 8

[Paul Morris [:pmorris]]

Comment on attachment 9121959 [details] [diff] [review]
1610400-timezone-fail-1.diff

Review of attachment 9121959 [details] [diff] [review]:
-----------------------------------------------------------------

Changes look okay to me.  I sanity checked to confirm that in cases like this the `formatter` variable is not reassigned when the error occurs on the right side of the assignment operator.  One suggestion on documenting what is going on here.

::: calendar/base/src/calDateTimeFormatter.js
@@ +70,5 @@
>        aOptions.timeZone = timezone.tzid;
> +      try {
> +        formatter = new Services.intl.DateTimeFormat(undefined, aOptions);
> +      } catch (ex) {
> +        cal.WARN(ex);

How about a comment to explain the problem we are try/catching here?  Or instead maybe in the catch log a warning that says something like "warning: there may be a problem due to a non-IANA timezone name."

Comment 9

[Geoff Lankow (:darktrojan)]

This already logs "RangeError: "invalid time zone in DateTimeFormat(): XYZ"" with a stack trace. I'll leave a comment in the code about IANA zones should anyone follow the error link back to it.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/f2e3b944020b
Fail gracefully when formatting a date with a timezone unknown to Services.intl. r=pmorris

Comment 11

[Rob Lemley [:rjl]]

Thunderbird 68.5.0:
https://hg.mozilla.org/releases/comm-esr68/rev/c6feba744006