Closed Bug 265911 Opened 20 years ago Closed 18 years ago

MozCal creates RRULE without UNTIL time specified - treates it differently than other calendar apps

Categories

(Calendar :: Internal Components, defect)

Product:
Calendar
Component:
Internal Components
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mattwillis, Unassigned)

Details

In trying to debug using Sunbird against Stalker's CommuniGate Pro, I ran into
this issue:

When you create a multiday event in MozCal/Sunbird and export it as an .ics, the
recurrence is specified like this:

RRULE
 :FREQ=DAILY;UNTIL=20041105;INTERVAL=1

1) MozCal/Sunbird does not add the (optional) time to UNTIL. Some apps will add
T000000Z to the UNTIL date, effectively changing UNTIL to the day before the day
specified (since no event can happen after 00:00:00Z on the UNTIL day). We
should add a time to UNTIL, preferably the end of the day, after the event.

2) MozCal/Sunbird treats the events below differently than other apps (ie:
CGPro, Apple iCal). 

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN
METHOD:PUBLISH
BEGIN:VEVENT
UID:d33913b8-1dd1-11b2-ad97-f60763b22fef
SUMMARY:test november events
PRIORITY:5
STATUS:CONFIRMED
CLASS:PRIVATE
X-MOZILLA-RECUR-DEFAULT-UNITS:days
RRULE:FREQ=DAILY;UNTIL=20041105;INTERVAL=1
DTSTART:20041103T233500Z
DTEND:20041104T003500Z
DTSTAMP:20041025T012543Z
LAST-MODIFIED:20041025T012840Z
BEGIN:VALARM
TRIGGER;VALUE=DURATION:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR

MozCal shows 3 events, on Nov. 3, 4, and 5. Importing this into Apple iCal or
CGPro adds only two events. Could this be because of issue #1?
  "The UNTIL rule part defines a date-time value which bounds the
   recurrence rule in an inclusive manner. If the value specified by
   UNTIL is synchronized with the specified recurrence, this date or
   date-time becomes the last instance of the recurrence."  [RFC2445s4.3.10]

Bug A:  The until time is 2004-11-05 00:00, which is before the 23:35 start
time, so the until datetime is before the third occurrence, and it should stop
at two occurrences.

Bug B:  Supposing the user wanted 3 occurrences in this case, the Until datetime
should be later, either:
  (a) take the 23:35 time from the start time.
  (b) provide a datetime picker that defaults to the 23:35 start time.
  (c) pick the next day if start time is not midnight.
Option (a) seems best to me. (Note that using the end time won't work well if
the duration is one day:  the until time would be synchronized with the start
time, so it would include an extra recurrence.)
Option (b) may not work well if the start time is later changed (it is not
obvious to the user that the until time needs to be changed).  Option (c) is
confusing with the "except if midnight" clause.


I vote for (c). That's what all the examples in rfc2445 do.
Just so I'm clear, if we were to implement (c) the line:
  RRULE:FREQ=DAILY;UNTIL=20041105;INTERVAL=1
would change to
  RRULE:FREQ=DAILY;UNTIL=20041106T000000Z;INTERVAL=1

Correct?
my reading of rfc2445 / 4.3.10 Recurrence Rule (BNF bit)
===
[snip]
               ( ";" "UNTIL" "=" enddate ) /
[snip]
     enddate    = date
     enddate    =/ date-time            ;An UTC value
===
is that EITHER a date OR a date-time is OK.  There is no need to force the hour
part.  It is the interpretation of the existing (and allowed for) yyyymmdd date
that is going wrong, I think.


> my reading of rfc2445 / 4.3.10 Recurrence Rule (BNF bit)
> ===
> [snip]
>                ( ";" "UNTIL" "=" enddate ) /
> [snip]
>      enddate    = date
>      enddate    =/ date-time            ;An UTC value
> ===
> is that EITHER a date OR a date-time is OK.  There is no need to force the hour
> part.  It is the interpretation of the existing (and allowed for) yyyymmdd date
> that is going wrong, I think.
> 
> 

Ok, so we have two issues:

1) MozCal, when creating a recurring event, needs to extend the UNTIL date by
one day, without a time.

2) MozCal, when interpreting a recurring event, needs to interpret an UNTIL date
without a time as 00:00:00 of the UNTIL date.

Is THIS correct?(In reply to comment #4)
(In reply to comment #5)
> Ok, so we have two issues:
> 
> 1) MozCal, when creating a recurring event, needs to extend the UNTIL date by
> one day, without a time.

Yes, I think so, i.e. Michiel's choice of (c)
 
> 2) MozCal, when interpreting a recurring event, needs to interpret an
> UNTIL date without a time as 00:00:00 of the UNTIL date.

I can't see anything in rfc2445 that says what the implied time of a DATE is but
it looks like other apps treat it as 00:00 i.e. 23:59 the previous day.

> Is THIS correct?(In reply to comment #4)

I'm not 100% on this but it looks OK to me.
(In reply to comment #5)
> 2) MozCal, when interpreting a recurring event, needs to interpret an UNTIL date
> without a time as 00:00:00 of the UNTIL date.

It looks like mozcal is the only thing that produces until without a time. So
changing the interpretation won't help interop, but will make mozilla interpret
it's own old files in a different way. Sounds like a bad idea.
(In reply to comment #7)

> It looks like mozcal is the only thing that produces until without a time. So
> changing the interpretation won't help interop, but will make mozilla interpret
> it's own old files in a different way. Sounds like a bad idea.

What is your suggestion?
(In reply to comment #7)
> (In reply to comment #5)
> > 2) MozCal, when interpreting a recurring event, needs to interpret an UNTIL date
> > without a time as 00:00:00 of the UNTIL date.
> 
> It looks like mozcal is the only thing that produces until without a time. So
> changing the interpretation won't help interop, but will make mozilla interpret
> it's own old files in a different way. Sounds like a bad idea.

Well, I'm not sure it's the ONLY thing that does this, but it was the only one I
found after a quick search.

The fact that MozCal created files wrong in the past is indeed unfortunate, but
that is also why point 1 is important. MozCal SHOULD include a time to be like
the others, and that time needs to be 00:00:00 of the day AFTER the last
occurence of the event.

How to handle any erroneously created .ics files is indeed an issue, and not one
I have an answer for at the moment. However, I do think that the more important
issue is fixing this issue pronto to stop making these flawed files.



I'd say to fix the creation of new rrules. But interpreting old values should
keep on ginving the same results.
The creation of correct rrules will make the incorrect ones go away automaticly.
So if it turns out that some other app creates rrules without a time, and
interprets it some other way, we can always change it. By that time, there are
no old style rules generated by mozcal anymore.
(In reply to comment #10)
> I'd say to fix the creation of new rrules. But interpreting old values should
> keep on ginving the same results.

I disagree and think Matt is right.

> The creation of correct rrules will make the incorrect ones go away
> automaticly.

Nope, we need to train usrers

> So if it turns out that some other app creates rrules without a time, and
> interprets it some other way, we can always change it. By that time, there are
> no old style rules generated by mozcal anymore.

You are an Idealistic person

(In reply to comment #11)
> (In reply to comment #10)
> > I'd say to fix the creation of new rrules. But interpreting old values should
> > keep on ginving the same results.
> 
> I disagree and think Matt is right.
> 
Why?
How does interpreting old rrules in the way mozcal always did harm anything? Why
is it bad?

> Nope, we need to train usrers

Why? To do what?
If an event is loaded with an old rules, and saved again, it will have the new
style rules. What does the user have to do?

> You are an Idealistic person

No, practical. Changing the way you parse the data you created is bad. It is
just plain dataloss. never do that.

(In reply to comment #7)
> It looks like mozcal is the only thing that produces until without a time.

Actually, after looking at some public ics files, it looks like apple ical
creates until without a time for all day event.

Does the interpretation of those differ also? Can someone test?
> RRULE:FREQ=DAILY;UNTIL=20041105;INTERVAL=1
> DTSTART:20041103T233500Z
> DTEND:20041104T003500Z
I wonder if the difference in interpretation comes from the timezone usage. The
end date is the next day. So the second event will end at 20041105. And that
means that it will be the last event.
It is not as much the lack of a time, but the endtime being the next day.
I have been quiet because I was hoping to test this with Lotus (since they were
one of the standards authors) but a whole lot of my java got broken (for
non-calendar or Lotus related reasons) and it may take me a few days until I
find time to repair the resulting mess to the point where I can test sensibly
with that app.  Sorry.

WRT recent comments: surely the right thing is to convert bad RRULES to good
ones on first use (if we can decide what the right thing is)?  Preferably as
part of the install and not as part of the app.  I see dragons in post
interpreting a non-converted file if the behaviour is changed.

(In reply to comment #14)
> > RRULE:FREQ=DAILY;UNTIL=20041105;INTERVAL=1
> > DTSTART:20041103T233500Z
> > DTEND:20041104T003500Z
> I wonder if the difference in interpretation comes from the timezone usage.
> The end date is the next day. So the second event will end at 20041105. And
> that means that it will be the last event. It is not as much the lack of a
> time, but the endtime being the next day.

rfc2445 / 4.3.10 Recurrence Rule
===
   The UNTIL rule part defines a date-time value which bounds the
   recurrence rule in an inclusive manner. If the value specified by
   UNTIL is synchronized with the specified recurrence, this date or
   date-time becomes the last instance of the recurrence.
===

I think Michiel may be onto a good clue here.  Perhaps other people will try
reading the standard again (I know I must) to see if the UNTIL cuts off the
DTEND (I think it should).  More importantly I think the UNTIL is the *end* of
an RRULE and MozCal isn't very good at TimeZone stuff at the moment so this may
be broader.

(My apols to Michiel if you thought I was rude earlier, I was just frustrated).
Assignee: mostafah → base
Component: libxpical → Base
QA Contact: gurganbl → base
The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!
Assignee: base → nobody
lilmatt, in my testing this bug now wfm.  We generate UNTIL with times, and interpret DATEs as exclusive, if that's how the ics gives them.  Any reason to keep this open?
No. I don't have CGPro to test against anymore anyways. :)

-> WFM
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.