Open Bug 308556 Opened 19 years ago Updated 2 years ago

RRULEs shouldn't be sent with Zulu time

Categories

(Calendar :: Internal Components, defect)

defect

Tracking

(Not tracked)

People

(Reporter: dmosedale, Unassigned)

Details

The consensus interpretation at the CalConnect interop seems to be that RFC 2445
should be interpreted to mean that RRULEs containing Zulu time are never
permitted.  Many implementations do seem to do so, however.  Mozilla Calendar is
one such implementation.

One relevant piece of RFC 2445 says:

   The "VTIMEZONE" calendar component MUST be present if the iCalendar
   object contains an RRULE that generates dates on both sides of a time
   zone shift (e.g. both in Standard Time and Daylight Saving Time)
   unless the iCalendar object intends to convey a floating time (See
   the section "4.1.10.11 Time" for proper interpretation of floating
   time). It can be present if the iCalendar object does not contain
   such a RRULE. In addition, if a RRULE is present, there MUST be valid
   time zone information for all recurrence instances.

There may well be more pieces of RFC 2445 that are relevant here too.
Hmmm.  After talking to some more folks the idea that there's really a consensus
on what correct behavior is seems less clear.
I think we should create all events either as floating or in a certain timezone.
That will prevent needing to check if the recurrence crossed dst changes. It is
also more logical: I don't care about at which time in GMT the event is, I care
about at which time it is here, where I live.
Unfortunately, I do not have cycles to work on Calendar stuff these days (just as it's getting to the good part!), so I am a bad owner for these bugs.  To delete the tragically-large chunk of bugspam, search for gregorianabdication.
Assignee: shaver → nobody
According to dmose on IRC this bug is about date/times inside the RRULE (and not about start/end date/times for events with RRULE.)

This seems in contrast with Bug 373667 that says that the until date in RRULE must be in UTC.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.