1265988 - Lightning prints a cryptic error message when it does not understand the timezone of an calendar event is seen

Status: NEW

(Calendar :: General, defect)

Description

[ISHIKAWA, Chiaki]

Summary:

- Please prefix error messages from lightening with an identifier
  string, say, "TB Cal:" or some such to figure out where the error is coming from.

- Also, for a particular error message, mentioned below, regarding unidentified or incorrect timezone,
  please mention a possible fix (say define the timezone locally(?)

- It is not entirely clear, though, what the error is exactly: Date format is incorrect (not RFC compliant)? The error message may want to say something about it.

Here is the news group exchange:
You can follow it in
https://groups.google.com/forum/#!topic/mozilla.dev.apps.thunderbird/M_CYFJ5nBBo

----

TB 45.0 32-bit under linux 64-bit

I noticed the following messages on the tty console window where I invoked
thunderbird lately.

Error: Couldn't find (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm,
Vienna

There are several such error lines and so I suspect it comes from a mailing
list or someone I correspond with.

There are a few problems with this error message.

It is not clear what the error is about.

Let me assume that this complains about incorrect Date: header line.

In that case, since the error message does not show the Subject: or From:, I
can't find out which e-mail or newsmessage produced the error message.
So I cannot figure out whose mailer/mail agent (or news reader) is broken.
Thus I cannot notify the user / sysadmin of the offending message (as if the
notified user/sysadmin will do something about it).

It would be great if the message can contain either From:, Subject: or
Message ID: line.
Or if it is not related to Date: header incorrectness, it ought to explain
what the "Error" is all about more clearly.

This is RFE (Request for Enhancement) in this sense.

Probably the issue here is that there is no control one has over the Date:
line of a received message.
We are at the mercy of whoever sends a message about the correct format of
header lines.
So I certainly understand the desire of developers to record the receiving
of a message with broken Date: header just in case, someoen cares about it, but
unless one has a clue as to who has sent such a message, there is nothing a
recipient can do.

TIA

----

On 19.04.2016 12:54, ishikawa wrote:
> TB 45.0 32-bit under linux 64-bit
>
> I noticed the following messages on the tty console window where I invoked
> thunderbird lately.
>
> Error: Couldn't find (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm,
> Vienna

This could be reported by Lightning: https://dxr.mozilla.org/comm-central/source/calendar/base/src/calTimezoneService.js#197

Maybe you have an event in your calendar that references the foreign timezone '(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm,
> Vienna' without providing its definition.

/Stefan

---


Thank you for the tips.
It is possible that the error is indeed caused by calendar code since
someone sent me a calendar event for skype conference call.
Usually, the e-mail goes through some internal hosts before I read it and
the event is registered in either google calendar and recently office365
calendar, and I have not bothered to check
the TB's built-in calendar...


So, I have not used lightening much because of the previous and current
usage of Google and Office365 calendar and
how to "define (UTC+1) ..." time zone.

At least, I can suggest that the error line


        let tz = this.mZones.get(tzid);
        if (!tz) {
            cal.ERROR("Couldn't find " + tzid);
            return null;


can have a prefix to identify the module (lightening) that prints the message.
So cal.ERROR ought to prefix the passed message with "TB Cal: " or some such.

Also, it would be great to mention a possible fix. "Please define the timezone ...
see this URL for help, etc.".

However, I have a nagging feeling that "UTC+1" should be a good enough
string to figure out the time zone even if
it is followed by unknown (?) city names. Maybe the use of "(", ")", etc.
may not fit the proper date format.

I will file an RFE in bugzilla.

Thank you again for identifying the place that produced the cryptic (at
least to me) message.

TIA

PS: now I noticed it is "UTC+01:00" instead of "UTC+01". That looks suspicious  although there are countries that have timezones with the difference from UTC in non-integral multiple of hour (01:00) so we do need to be able to express such timezone differences somehow.

PPS: No, I don't use calendar/lightening feature very much and so not sure where the code should be touched.

Comment 1

[ISHIKAWA, Chiaki]

I noticed the following bug which may be related to incorrect date string parsing, but
I am not sure if that bug is related to this bugzilla entry. 
Bug 729685 - Wrong Timezone with ics (iCal) import to Lightening

Comment 2

[ISHIKAWA, Chiaki]

Another data point from bj66.chan in dev-apps-thunderbird mailing list.

Lightning 4.7 in Windows 10 has the similar issue. When received Webex meeting invitation, the timezone cannot be recognized. It will use the default UTC timezone for the event.


PS: my own conclusion. It looks timezone code in lightening can be improved ?

Comment 3

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

There can certainly be some improvements, we could be mapping some well known Microsoft Timezone names to Olson names. I'm already doing this for some timezone names the gdata provider, the code may just need to be moved over and those extra names added.

It would be good to see the ics file this event comes from. If it has a VTIMEZONE component mentioning "(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna" then this is not only a display bug, otherwise it is.

Back in the days there were some talks about better error collection UI, but no one stepped up to provide some good UI for this, as in most cases the timezones are correct. The problem is that we don't want to bug the user with any dialogs in case he doesn't care, but on the other hand want to fix the timezone issues in a smart way.

Until someone has a great UI concept for this I'd suggest just adding those stray timezone names to the zones.json aliases.