Closed
Bug 577023
Opened 11 years ago
Closed 9 years ago
The until date of a repeating event changes from UTC time to floating after Thunderbird is closed and restarted.
Categories
(Calendar :: Provider: Local Storage, defect)
Calendar
Provider: Local Storage
Tracking
(Not tracked)
RESOLVED
FIXED
1.4
People
(Reporter: bv1578, Assigned: bv1578)
Details
Attachments
(3 files)
941 bytes,
patch
|
Taraman
:
review+
|
Details | Diff | Splinter Review |
1.33 KB,
patch
|
Fallen
:
review+
|
Details | Diff | Splinter Review |
777 bytes,
text/plain
|
Details |
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
Updated•11 years ago
|
Flags: blocking-calendar1.0?
Comment 1•11 years ago
|
||
This seems specific to storage provider because I can't reproduce using ics provider.
Component: Internal Components → Provider: Local Storage
QA Contact: base → storage-provider
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.
Updated•11 years ago
|
OS: Windows XP → All
Hardware: x86 → All
Comment 3•11 years ago
|
||
Comment on attachment 457320 [details] [diff] [review] patch-v1 short patch - no further comments. r=markus
Attachment #457320 -
Flags: review?(Mozilla) → review+
Comment 4•11 years ago
|
||
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/4019a33839df> -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0b3
Updated•11 years ago
|
Flags: blocking-calendar1.0?
Comment 5•11 years ago
|
||
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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 7•10 years ago
|
||
Yes, I understand this passage from rfc5545 the same way. So we are doing it wrong?
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.
Attachment #545136 -
Flags: review?(philipp)
Comment 9•10 years ago
|
||
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.
Attachment #545136 -
Attachment description: patch - v2 → [after beta] patch - v2
Comment 10•10 years ago
|
||
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 11•10 years ago
|
||
Comment on attachment 555356 [details]
Testcase - v1
Sorry, I should give credit to jean-louis who originally reported this bug on irc.
Attachment #555356 -
Attachment mime type: text/calendar → text/plain
Assignee | ||
Comment 12•10 years ago
|
||
(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.
Updated•10 years ago
|
Status: REOPENED → ASSIGNED
Target Milestone: 1.0b3 → ---
Comment 13•9 years ago
|
||
Pushed to comm-central changeset 6bb7dbe6d90c
Status: ASSIGNED → RESOLVED
Closed: 11 years ago → 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4
Comment 14•9 years ago
|
||
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.
Attachment #545136 -
Flags: review?(philipp) → review+
You need to log in
before you can comment on or make changes to this bug.
Description
•