384700 - RDATE/EXDATE specified timezones get lost during ICS roundtrip

Status: VERIFIED FIXED

(Calendar :: Internal Components, defect)

Description

[Daniel Boelzle [:dbo]]

When specifying a TZID for RDATE/EXDATE properties, those get lost when writing ics.

Comment 1

[Daniel Boelzle [:dbo]]

Attachment: fix

- taking bug
- fixing bug
- streamlining the bloody AddtimeZoneReference thing, adding a calIIcalProperty::valueAsDatetime attribute, which used by calRecurrenceDate
- some const correctness fixes

Comment 2

[Daniel Boelzle [:dbo]]

Attachment: sample file (depends on fixes from bug 381415)

Comment 3

[Daniel Boelzle [:dbo]]

Comment on attachment 268614 [details] [diff] [review]
fix

Since mvl doesn't have any time left, shifting review to Clint.
We should clarify if it is mandatory to preserve the TZID at all (which is handled by the patch). An alternative would be to convert RDATE/EXDATEs to UTC upon reading; writing is in UTC which IMO doesn't hurt. The only drawback is that UI (namely the recurrence dialog) should present EXDATEs in a sensible timezone, thus needs to convert.

Comment 4

[Daniel Boelzle [:dbo]]

How to verify:
1. Subscribe to the attached ics file.
2. Modify the ics file, e.g. create a new event.
=> The ics file won't contain the VTIMEZONE for Europe/Paris anymore, thus the RDATE has a dangling TZID.

Comment 5

[cmtalbert]

Comment on attachment 268614 [details] [diff] [review]
fix

>Index: public/calIICSService.idl
>===================================================================
>+    /**
>+     * The value of the property as date/datetime value, keeping
>+     * track of the used timezone being resolvable and referenced in the
>+     * owning component.
>+     * XXX todo: or add [noscript, notxpcom] getter/setter?
>+     */
>+    attribute calIDateTime valueAsDatetime;
I don't see the need for [noscript, notxpcom] here.  Please explain and/or add a follow-on bug for it. 

Otherwise, looks OK.

Comment 6

[Daniel Boelzle [:dbo]]

Checked in on HEAD and MOZILLA_1_8_BRANCH.

Comment 7

[Andreas Treumann]

Verified in nightly build 20070821, task is fixed.