1212914 - timezone handling differs between libical and ical.js

Status: RESOLVED WORKSFORME

(Calendar :: ICAL.js Integration, defect)

Description

[Philipp Kewisch [:Fallen][📱📆]]

There is some slightly different handling to the default timezone between libical and ical.js see attachment 8645744 [details] [diff] [review] and search for "ical.js and libical currently have slightly different timezone handling".

ical.js assumes floating timezone if it can't figure out the timezone. I'm fine with changing the behavior to be more sane, as long as it is the same between libical and ical.js

Comment 1

[Stefan Sitter [:ssitter]]

Bug 1149470 is about ical.js and foreign timezones. Is this bug about the same issue? In my opinion it is a blocker to enable ical.js because it renders Lightning useless when used with calendars from foreign sources. Or with calendars created in previous Lightning/Sunbird releases that allowed to set timezones that no longer exists today.

Comment 2

[Philipp Kewisch [:Fallen][📱📆]]

This one is slightly different, but it may of course happen that the other bug fixes this one. the libical wrapper code has some strange handling on when the timezone is changed to floating, it seems to happen as a side-effect of other code and is not easy to influence from calling code.

I agree the timezone issues are important to enable ical.js, maybe aside from the bugzilla component itself we should create a meta bug for issues required to enable ical.js for non-nightly builds.

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to Philipp Kewisch [:Fallen] from comment #2)
> ...
> I agree the timezone issues are important to enable ical.js, maybe aside
> from the bugzilla component itself we should create a meta bug for issues
> required to enable ical.js for non-nightly builds.

not bug 978570?

Comment 4

[Philipp Kewisch [:Fallen][📱📆]]

That meta bug is sufficient, thanks for the note.

Comment 5

[Magnus Melin [:mkmelin]]

libical has now been removed - bug 1787097.