This bug is very similar to bug 373667 but happens after Thunderbird is closed and restarted. Steps to reproduce: 1. create an event with any custom repeating rule and an until date (don't change the default start date-time proposed in the dialog to avoid bug 566149) e.g. start date-time 2010/07/05 18:0 end date-time 2010/07/05 19:00 repeat monthly, the 5th of the month, until 2011/07/27 2. save the event; 3. export the calendar in ics format; 4. close and restart Thunderbird; 5. don't modify the event and export again the calendar in ics format. Actual result: after step 3 the until date is in UTC format and with a correct value (the same as the start time value but in UTC format) e.g. BEGIN:VEVENT CREATED:20100705T152858Z LAST-MODIFIED:20100705T152917Z DTSTAMP:20100705T152917Z UID:1aefc9c9-2dfe-4838-8e51-396bbe387f43 SUMMARY:New Event RRULE:FREQ=MONTHLY;UNTIL=20110727T160000Z;BYMONTHDAY=5 DTSTART;TZID=Europe/Berlin:20100705T180000 DTEND;TZID=Europe/Berlin:20100705T190000 END:VEVENT after step 5 the until date is floating but with the same previous date and time, which is wrong as floating e.g. RRULE:FREQ=MONTHLY;UNTIL=20110727T160000;BYMONTHDAY=5 Expected result: until date timezone shouldn't change and should be always in UTC format. Reproducible: always. The same occurs with Lightning 0.9 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8pre) Gecko/20100705 Lightning/1.0b2pre Lanikai/3.1.1pre
This seems specific to storage provider because I can't reproduce using ics provider.
Created attachment 457320 [details] [diff] [review] patch-v1 It seems that the function "newDateTime()" needs the timezone parameter "UTC" for the until date assignment otherwise it returns by default a date with a "floating" timezone. This patch seems working fine with anything else to add.
Comment on attachment 457320 [details] [diff] [review] patch-v1 short patch - no further comments. r=markus
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/4019a33839df> -> FIXED
Backported to comm-1.9.2 <http://hg.mozilla.org/releases/comm-1.9.2/rev/33a7cf398f80> a=philipp
I think this bug must be reopened. I've just seen two events exported from Google calendar and the until date is not always in UTC format. a normal repeating event: DTSTART;TZID=Europe/Paris:20110605T100000 DTEND;TZID=Europe/Paris:20110605T110000 RRULE:FREQ=DAILY;UNTIL=20110630T080000Z <-- UTC an all day repeating event: DTSTART;VALUE=DATE:20110605 DTEND;VALUE=DATE:20110606 RRULE:FREQ=DAILY;UNTIL=20110630 <-- Floating! RFC 5545 (http://tools.ietf.org/html/rfc5545#section-3.3.10 pag. 40) says: ... The value of the UNTIL rule part MUST have the same value type as the "DTSTART" property. Furthermore, if the "DTSTART" property is specified as a date with local time, then the UNTIL rule part MUST also be specified as a date with local time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time. In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL rule part MUST always be specified as a date with UTC time. If specified as a DATE-TIME value, then it MUST be specified in a UTC time format. to sum up, the until date should always be UTC except when DSTART is in local time. Stefan, Philipp, is this the right meaning of the text in RFC 5545?
Yes, I understand this passage from rfc5545 the same way. So we are doing it wrong?
Created attachment 545136 [details] [diff] [review] [after beta] patch - v2 As far as I can see, the until-date is stored only as native-time format without other informations about the type (isDate) or the timezone (floating or UTC), so I've used the item's start date to select the until-date type. The patch solves the issue mentioned in comment 6 according to RFC (in particular, when "DTSTART" is date and local time, the same must be the until date). I'm not completely sure if it needs some extra controls to avoid any kind of problem.
Comment on attachment 545136 [details] [diff] [review] [after beta] patch - v2 I think its fine the way it is, but I'd like to push this after 1.0b5 to avoid the risk of last minute regressions. Leaving in my queue so I don't forget.
Created attachment 555356 [details] Testcase - v1 Not 100% this bug, but I found an error with the until date being saved in UTC. If you subscribe to this calendar as an ics calendar, then the last occurrence of three is not shown since the until date is before the last occurrence (due to timezone differences). I haven't checked if the patch fixes this issue, but maybe it could be taken into account.
Comment on attachment 555356 [details] Testcase - v1 Sorry, I should give credit to jean-louis who originally reported this bug on irc.
(In reply to Philipp Kewisch [:Fallen] from comment #10) > Created attachment 555356 [details] > Not 100% this bug, but I found an error with the until date being saved in > UTC. If you subscribe to this calendar as an ics calendar, then the last > occurrence of three is not shown since the until date is before the last > occurrence (due to timezone differences). I haven't checked if the patch > fixes this issue, but maybe it could be taken into account. Not sure, but it could be bug 566149. It would need to know how the event has been created. If the user changed the start date to an earlier date/hour before selecting the until date, for sure it's that bug. See also the duplicate bug 581880 where the timezone difference seemed the cause.
Pushed to comm-central changeset 6bb7dbe6d90c
Comment on attachment 545136 [details] [diff] [review] [after beta] patch - v2 Review of attachment 545136 [details] [diff] [review]: ----------------------------------------------------------------- r=philipp, I'll take care of the push. ::: calendar/providers/storage/calStorageCalendar.js @@ +1535,5 @@ > + let untildate = newDateTime(row.end_date, allday ? "" : "UTC"); > + if (allday) { > + untildate.isDate = true; > + } > + ritem.untilDate = untildate.clone(); No need to clone since you are creating a new date time object a few lines above and not further using it.
or
