Closed Bug 388094 Opened 13 years ago Closed 13 years ago
Alarm time exported incorrectly to i
Calendar format (.ics) when time is greater than 7 days (or the equivalent in hours or minutes).
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:220.127.116.11) Gecko/20070515 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:22.214.171.124pre) Gecko/20070614 Sunbird/0.5 If you set an alarm time greater than 7 days, or, which is equivalent, 168 hours or 10080 minutes, when you export the calendar to iCalendar format (.ics), the generated iCalendar file contains the error "TRIGGER:ERROR: No Value" when the alam is before, or "TRIGGER;RELATED=END:ERROR: No Value" when the alarm is after. Note that the alarm time is exported correctly when it is a multiple of 7 days, for example 21 days, 336 hours, 20160 minutes, etc. The iCalendar file is generated without displaying any error. The problem is only related to the export to iCalendar format. The alarm time is stored correctly inside Sunbird. Reproducible: Always Steps to Reproduce: 1. create an event, set an alarm for it, and set the alarm time to a value greater than 7 days (or, which is equivalent, 168 hours or 10080 minutes) 2. export the calendar with this event to iCalendar format Now repeat the steps, but change step 1 setting an alarm time multiple of 7 days. Actual Results: Open the generated .ics file with a text editor and look for the section containing the event BEGIN:VEVENT and then BEGIN:VALARM. You will see the error: TRIGGER:ERROR: No Value (when the alam is before) TRIGGER;RELATED=END:ERROR: No Value (when the alam is after) When the alarm time is multiple of 7 days, you will find a valid value: TRIGGER;VALUE=DURATION;RELATED=END:P2W (example of an alarm time of 14 days). Expected Results: If you set an alarm time of 9 days, for example, you should get: TRIGGER;VALUE=DURATION;RELATED=END:P1W2D PLEASE CHECK THIS POINT WITH ICALENDAR STANDARD. The problem has been verified with Sunbird 0.5 (Italian locale), on Windows XP SP2 Home Edition and Linux openSUSE 10.2 (both Italian language).
Confirmed using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060507 Mozilla Sunbird/0.3a2. It works using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051104 Mozilla Sunbird/0.3a1 so it looks like a regressed between 0.3a1 and 0.3a2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
WORKS in sunbird-0.3a1+.en-US.win32-2006-02-23-07-trunk .ics file shows TRIGGER;VALUE=DURATION:-P8D FAILS in sunbird-0.3a1+.en-US.win32-2006-02-24-07-trunk to FAILS in sunbird-0.3a1+.en-US.win32-2006-02-28-10-trunk .ics file shows TRIGGER;VALUE=DURATION:PT8H14M56S FAILS in sunbird-0.3a1+.en-US.win32-2006-03-01-06-trunk .ics file shows TRIGGER:ERROR: No Value Checkins between 2006-02-23 07:00 and 2006-02-24 08:00 : Bug 315051 [http://tinyurl.com/222ml9] Checkins between 2006-02-28 10:00 and 2006-03-01 07:00 : Bug 328653, Bug 328761, Bug 328763 [http://tinyurl.com/2xw9sj] I narrowed down the error location to the following lines: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/calendar/base/src/calItemBase.js&rev=1.72&mark=694#688 var triggerProp = icssvc.createIcalProperty("TRIGGER"); triggerProp.valueAsIcalString = this.alarmOffset.icalString; Additional dump statements showed that the alarm offset is correct but valueAsIcalString somehow fails: Output for alarm offset 14 days: fillIcalComponentFromBase() called this.alarmOffset.icalString = -P2W triggerProp.icalString = TRIGGER;VALUE=DURATION:-P2W Output for alarm offset 8 days: fillIcalComponentFromBase() called this.alarmOffset.icalString = -P1W1D triggerProp.icalString = TRIGGER:ERROR: No Value The question is: Why does valueAsIcalString fails?
This could be considered a dataloss bug -> blocking‑calendar0.7 ? Someone with enough knowledge of the internal components (libical?) should check why valueAsIcalString() fails for this duration values.
Component: Import and Export → Internal Components
OS: Windows XP → Windows 2000
QA Contact: import-export → base
Parsing -P1W1D fails due to a strict rfc2445 check (section 4.3.6): dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) A duration can either be specified in weeks or days, but not in both. The question is: how are those strings generated, and should we make the parser less strict? (the parser is in libical btw, and I don't know what the latest libical does here)
Right, it's invalid ics. IMO shouldn't assume that libical normalizes the duration, i.e. transforms the weeks field into more days. We could easily workaround that problem in calDuration by not setting icaldurationtype's week field in that case.
Assignee: nobody → daniel.boelzle
Status: NEW → ASSIGNED
Attachment #280053 - Flags: review?(mvl)
BTW: Setting a customized reminder (e.g. 169 hours), saving then reopening states 1 hour. Moreover the reminder is lost once I change e.g. the title of the event. Anybody knows whether this has already been filed?
(In reply to comment #6) I think this is the same issue as in Bug 395288 (169 hours == 7 days + 1 hour).
Comment on attachment 280053 [details] [diff] [review] fixing normalize (which calls setinSeconds) My personal would be to not use the ?: operator, but use an explicit if. Do with that whatever you like :) r=mvl anyway. Should we change libical to be more forgiving when it sees invalid ics like this, as additional fix? ("be liberal in what you accept" and all that)
Attachment #280053 - Flags: review?(mvl) → review+
(In reply to comment #8) > Should we change libical to be more forgiving when it sees invalid ics like > this, as additional fix? ("be liberal in what you accept" and all that) IMO we shouldn't do that. We could think about roundtripping that invalid ics "as-is" (disallowing any modification), but that's optional.
Checked in on HEAD and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.7
Verified in lightning 2007091204 and sunbird 20070912 -> task is fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.