1806836 - Calendar is not recognising correctly time zone names from event invitations - Could not find definition for US Mountain Standard Time

Status: RESOLVED DUPLICATE of bug 1149470

(Calendar :: General, defect)

Description

[George]

Attachment: evt.ics

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

Steps to reproduce:

Import the attached ICS; my current time zone is Europe/Vienna.

Latest macOS, latest thunderbird nightly at the time of submitting this bug.

Actual results:

The event is shown to start at 9:00am. I'm guessing that 'US Mountain Standard Time' present in the ics file is not recognised as a time zone.

If this event invitation is included in an e-mail message, the time displayed inside the message view is also incorrect.

Expected results:

The software should treat 'US Mountain Standard Time' as equivalent to America/Phoenix, and the event starting time (when converted to Europe/Vienna local timezone) should be shown as 5:00pm (or 17:00).

Apple Calendar and SOGo Webmail built-in Calendar show this entry correctly.

Comment 1

[Magnus Melin [:mkmelin]]

Error console: Could not find definition for US Mountain Standard Time

Works fine in 102.

Comment 2

[George]

'Pacific Standard Time' is also not recognised, so I'd assume that the entire set of zone definitions was somehow lost.

Comment 3

[Sean Burke [:leftmostcat]]

It looks like we did have some explicit support for mapping "US Mountain Standard Time", but we should still be able to use the definition provided in the VTIMEZONE component of the ICS file. I think the solution to this will be figuring out why that definition is not being correctly used.

Comment 4

[George]

Both 'US Mountain Standard Time' and 'Pacific Standard Time' (from a different ICS) are not recognised. I'm assuming (according to the header) that the file came from Microsoft Exchange Server. I recall seeing zones.json file somewhere within Mozilla source base that contained all of these zones as aliases.

Comment 5

[Andrei [:sancus]]

We're using the ICU timezone database now, so zones.json was removed. But as Sean said, we shouldn't need to have hardcoded time zones with those names if they're defined as VTIMEZONE in the ics file. And we do want VTIMEZONE to work properly since people could be using time zones named anything.

Comment 6

[Martin Schröder [:mschroeder]]

(In reply to Sean Burke [:leftmostcat] from comment #3)

It looks like we did have some explicit support for mapping "US Mountain Standard Time", but we should still be able to use the definition provided in the VTIMEZONE component of the ICS file. I think the solution to this will be figuring out why that definition is not being correctly used.

This is bug 1149470.

Comment 7

[George]

Please make sure that DST is handled correctly. I saw that the same ICS files created/reexported through different software sometimes had times offset by 1 hour compared to each other.

Comment 8

[Andrei [:sancus]]

(In reply to Martin Schröder [:mschroeder] from comment #6)

(In reply to Sean Burke [:leftmostcat] from comment #3)

It looks like we did have some explicit support for mapping "US Mountain Standard Time", but we should still be able to use the definition provided in the VTIMEZONE component of the ICS file. I think the solution to this will be figuring out why that definition is not being correctly used.

This is bug 1149470.

Thanks Martin. We'll need to bump up the priority of fixing this since we lost any non-ICU TZ definitions.

Comment 9

[George]

The other bug is 8 years old. I'm pretty sure this issue is recent.

Comment 10

[Andrei [:sancus]]

(In reply to George from comment #9)

The other bug is 8 years old. I'm pretty sure this issue is recent.

The other bug was papered over by the list in zones.json -- we shouldn't add arbitrary timezones made up by applications to a fixed file. VTIMEZONEs should work as they're intended to. We're not bringing zones.json back or anything like that.