Wrong Timezone with ics (iCal) import to Lightning
Categories
(Calendar :: Import and Export, defect)
Tracking
(thunderbird_esr140 wontfix, thunderbird147 wontfix)
People
(Reporter: kwagner9, Assigned: dev)
References
Details
(Keywords: testcase)
Attachments
(3 files)
Clear issue between imported meeting vs. import window
|
||
Comment 1•14 years ago
|
||
|
Reporter | |
Comment 2•14 years ago
|
||
|
||
Comment 3•6 years ago
|
||
(In reply to Stefan Sitter [:ssitter] from comment #1)
The problem with the ics file created by Outlook is obvious: The defined and
the referenced timezone are different, at least for a computer. The sample
defines timezone A but references "A".The latter seems to be a violation of iCalendar specification RFC 5545 too:
so this bug is INVALID?
(In reply to Karl Wagner from comment #2)
I originally thought the same, but taking the quotes away doesn't make a
difference. For example, if you use the following input file that doesn't
have quotes (no spaces in the TZID), the same problem occurs:
but there is another bug?
|
|
||
Updated•6 years ago
|
|
||
Updated•5 years ago
|
Hi, I also came across the same problem.
The time of my Microsoft teams meeting invitation is 12:00-12:45 UTC +1:00 (which equals to BST/GMT+1) and Lightening only shows me the wrong time in 11:00-11:45 GMT. I am not sure if this is because Lightening can't handle summer time change or for other reasons.
The ics file is here:
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Romance Standard Time
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Romance Standard Time:20210415T120000
DTEND;TZID=Romance Standard Time:20210415T124500
(In reply to fuqi from comment #4)
My apologies. Please ignore the comment above.
It turns out the time displayed in the calendar was correct. However, in the calendar invitation, it shows conflicting information and caused some confusion. No action is needed for this ticket.
the original time:
When: Thursday, 15 April 2021 11:00 – 11:45 (displayed in local time BST)
the time in the forwarded meeting invitation:
When: 15 April 2021 12:00-12:45 (UTC+01:00) Brussels, Copenhagen, Madrid, Paris.
The second one is incorrectly displayed and caused confusion. but Lightning handled the meeting time correctly.
|
||
Updated•3 years ago
|
An example event file where the timezone is detected wrong.
"US Mountain Standard Time" is not recognised by Thunderbird/Lightning, and it replaces it with the default recipient timezone.
|
||
Comment 7•3 years ago
|
||
I had the same problem. The ICS contains:
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Eastern Standard Time
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
[...]
DTSTART;TZID=Eastern Standard Time:20230120T130000
DTEND;TZID=Eastern Standard Time:20230120T133000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20230112T121527Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:Microsoft Teams Meeting
[...]
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
I got the meeting scheduled in calendar in my timezone (at 1PM), instead of using the provided timezone.
Calendar software also corrupts the existing events in Exchange/IMAP server account when touched.
Maybe the severity should be bumped to a higher level than S3/normal?
The bug is 11 years old and may look misleadingly under-prioritised. Actually, the issue is recent and fairly serious (developers got rid of zones.json that plugged it), and there's no workaround.
Most calendaroholics are using Microsoft or MS-compatible tools, and this bug corrupts all events that come from a non-local timezone (virtually all remote work these days).
Note how the import window already gets it wrong (I am in EET, so +1 in relation to Berlin, NOT a 2h time difference), and how the calendar itself later on neatly corrects for the issue, by simply updating the ORIGINAL time (rather than correctly adjusting for my local time, immediately).
|
||
Comment 10•2 years ago
|
||
See also image I just added, above.
Here is another piece of support for this issue to be checked & fixed. I agree this deserves much higher priority. People (can) get into big issues becasue of this, and it is such a fundamental thing you trust. I hope this can be solidly resolved, very rapidly... 11 years, wow!
Also look at the references e.g. the closed one dealing with 'MS formatting' of time zones in ICS files, fixed in 113. Cool, but how is this still a thing, now, then?
Question: could it be that this issue is caused by incorrect/suboptimal creation of ICS files by parties such as addevent.com? They seem to be the party behind the particular ICS files I am dealing with, at the moment.
ICS:
BEGIN:VCALENDAR
PRODID:-//AddEvent Inc//AddEvent.com v1.7//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:STANDARD
DTSTART:20241027T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20240331T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20240311T134610Z
STATUS:CONFIRMED
[...]
SEQUENCE:0
DTSTART;TZID=Europe/Berlin:20240320T160000
DTEND;TZID=Europe/Berlin:20240320T173000
SUMMARY:Liquid Hydrogen Distribution
DESCRIPTION:Register now for the\nfree webinar: www.mission-hydrogen.com http://www.mission-hydrogen.com\n\n
X-ALT-DESC;FMTTYPE=text/html:<p style="margin:0in;font-family:Calibri;font-size:11.0pt;">Register now for the<br />free webinar: <a href="http://www.mission-hydrogen.com">www.mission-hydrogen.com</a></p><br />
LOCATION:www.mission-hydrogen.com
BEGIN:VALARM
TRIGGER:-PT30M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
|
||
Comment 11•2 years ago
|
||
Hi,
@u751501,
For the record, can you confirm version of Thunderbird you used when reporting issue as well as operating system?
@Wayne,
Does that mean we can change status of this bug to New in the hope it may be picked up by the dev team for possible fixing?
Cheers,
|
|
||
Comment 12•2 years ago
|
||
(In reply to Richard Leger from comment #11)
Hi,
@u751501,
For the record, can you confirm version of Thunderbird you used when reporting issue as well as operating system?
This person disabled their bugzilla account.
@Wayne,
Does that mean we can change status of this bug to New in the hope it may be picked up by the dev team for possible fixing?
I don't have great knowledge in this area.
|
||
Comment 13•2 years ago
|
||
(In reply to u751501 from comment #10)
See also image I just added, above.
Here is another piece of support for this issue to be checked & fixed. I agree this deserves much higher priority. People (can) get into big issues becasue of this, and it is such a fundamental thing you trust. I hope this can be solidly resolved, very rapidly... 11 years, wow!
Also look at the references e.g. the closed one dealing with 'MS formatting' of time zones in ICS files, fixed in 113. Cool, but how is this still a thing, now, then?Question: could it be that this issue is caused by incorrect/suboptimal creation of ICS files by parties such as addevent.com? They seem to be the party behind the particular ICS files I am dealing with, at the moment.
The problem is there is no single bug. There's a lot of ways that VTIMEZONES can go wrong. This bug is old, and has already referenced more than one possible way for that to happen. So it's not like it hasn't been prioritized -- it doesn't even represent a single, comprehensible bug.
In this particular case, what's going on here is this ICS file has bad DTSTARTs in the DAYLIGHT and STANDARD blocks. DTSTART:20241027T020000 is nonsensical and should actually be something like DTSTART:19701027T020000. The purpose of this is to define the DST dates, but if you define them in the future and don't mean that, it's not really possible for the client to know what you do mean. Because in a VTIMEZONE block it's possible to define DST dates that differ from the current ones or the standard ones, which would be necessary and useful when timezone definitions change for example, which they regularly do.
I have no idea if this aligns with the original bug reported or not because it takes like 45 minutes to figure out what's gone wrong for EACH ICS file that has a VTIMEZONE in it.
Is this a bug we can fix? Possibly, yes, though we'll have to be careful to not break legitimate VTIMEZONES that are trying to redefine DST dates in the future. Not my area of expertise though, so hopefully this post is useful to whichever engineer ends up fixing this particular DTSTART issue.
|
||
Comment 14•6 months ago
|
||
This bug is affecting us locally on Thunderbird, but we also noticed that the same issue is also affecting the Roundcube plugin that is the default in CPanel called "Kolab/Calendar". The source code of which is at https://github.com/kolab-roundcube-plugins-mirror/calendar. I'm wondering if there is possible library being shared upstream.
In our case, Outlook/Exchange/Entourage has deviated from the standard "Australia/Melbourne" to give us only VTIMEZONE data specified as "Canberra, Melbourne, Sydney" which results in all our invites received from Outlook/Exchange/Entourage defaulting to UTC.
Confusingly, Entourage also sends "X-ENTOURAGE-CFTIMEZONE:Australia/Canberra".
e.g.:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Microsoft Corporation//Outlook for Mac MIMEDIR//EN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:"Canberra, Melbourne, Sydney"
X-ENTOURAGE-CFTIMEZONE:Australia/Canberra
X-ENTOURAGE-TZID:51
BEGIN:STANDARD
RRULE:FREQ=YEARLY;INTERVAL=1;BYSECOND=0;BYMINUTE=0;BYHOUR=3;BYDAY=1SU;BYMO
NTH=4
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
DTSTART:20080406T030000
END:STANDARD
BEGIN:DAYLIGHT
RRULE:FREQ=YEARLY;INTERVAL=1;BYSECOND=0;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMO
NTH=10
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
DTSTART:20081005T020000
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:redacted
X-ENTOURAGE_UUID:redacted
DTSTAMP:20250808T020051Z
DTSTART;TZID="Canberra, Melbourne, Sydney":20250812T070000
DTEND;TZID="Canberra, Melbourne, Sydney":20250812T090000
|
Assignee | |
Comment 15•2 months ago
|
||
This patch fixes calendar import from Exchange/Office 365 servers that use
Windows timezone names (e.g., "Romance Standard Time") by converting them to
IANA timezone IDs (e.g., "Europe/Paris") using ICU's built-in
TimeZone::getIDForWindowsID() function.
The conversion is attempted before timezone lookup and falls back to the
original ID if conversion fails, making this change backward compatible.
Includes corresponding test.
|
||
Updated•2 months ago
|
|
|
Assignee | |
Comment 16•2 months ago
|
||
I have recently tried to switch to using Thunderbird exclusively on my linux machines for interfacing with my work email, and I have had problems with the timezones being in a non IANA format coming from the Exchange server.
The diff I submitted to phabricator should address the timezone mismatch from Windows/Exchange calendar events. I have also, in the meantime, created a simple extension that works with Thunderbird for just statically mapping the windows timezones to an IANA equivalent. You can find the source code and an XPI here: https://github.com/zeyus/thunderbird-windows-timezone-fix
|
||
Updated•2 months ago
|
|
||
Comment 17•2 months ago
|
||
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/df1e574ed722
Add Windows timezone name support using ICU conversion. r=mkmelin
Description
•