32.26 KB, image/png
29.32 KB, image/png
35.02 KB, image/png
35.34 KB, image/png
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20070309 Firefox/18.104.22.168 Build Identifier: 0.3.1 This is the top of my ICS file: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//-RemoteCalendars, http://remotecalendars.sf.net METHOD:PUBLISH BEGIN:VTIMEZONE TZID:Canada/Eastern BEGIN:DAYLIGHT DTSTART:20070311T020000 TZOFFSETFROM:-0-500 TZOFFSETTO:-0-400 END:DAYLIGHT BEGIN:STANDARD DTSTART:20071105T020000 TZOFFSETFROM:-0-400 TZOFFSETTO:-0-500 END:STANDARD END:VTIMEZONE Here's a 7AM event: UID:667 DTSTART;TZID=Canada/Eastern:19981218T070000 DTEND;TZID=Canada/Eastern:19981218T100000 SUMMARY:Garbage Collection DESCRIPTION:Garbage Collection LOCATION:Ottawa RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=FR STATUS:NOT SPECIFIED END:VEVENT BEGIN:VEVENT Lightning shows it as being at 3AM. Rainlendar http://www.rainlendar.net/ , on the other hand, displays it correctly at 7AM. I have the impression that Lightning is applying the -4h offset one extra time or something. Reproducible: Always Steps to Reproduce: Use the ICS data I pasted. Actual Results: 3AM event Expected Results: 7AM event I believe the software is getting confused by the fact that the file define its default Timezone at the top, and the event defines its own Timezone. I think the software is subtracting 4h again, incorrectly.
Marcio, for me it looks like the TZOFFSET parameters have the wrong format. From the file format specification (RFC 2445): "Example: The following are examples of this property: TZOFFSETFROM:-0500 TZOFFSETFROM:+1345" And in your file: "TZOFFSETFROM:-0-500 TZOFFSETTO:-0-400"
I will check with the author of the tool which created the file (Remote Calendars). In fact I entered a bug report against it: https://sourceforge.net/tracker/?func=detail&atid=758187&aid=1716601&group_id=144247
I have come across the same type of issue. When using the prototype Event picker. Any hour picked is displayed as 4 hours behind after selection is complete.
(In reply to comment #1) > Marcio, for me it looks like the TZOFFSET parameters have the wrong format. > I changed to: TZOFFSETFROM:-0500 TZOFFSETTO:-0400 but Lightning still did not display it properly. And Rainlendar still displayed it properly.
1. Uninstalling lighting 2. removing all calendar.* prefs from config 3. restarting thunderbird 4. reinstalling lighting and resetting prefs corrected this error for me.
(In reply to comment #6) > I changed to: > > TZOFFSETFROM:-0500 > TZOFFSETTO:-0400 > > but Lightning still did not display it properly. Marcio, did you change those entries for DST and non-DST part of VTIMEZONE? I tested your (corrected) ICS file with a nightly build of Lightning and set the Lightning timezone to America/Toronto. After opening the calendar file, the calendar view shows the event at 7am.
Yes, I changed in both places and it is still wrong (Lightning 0.3.1). Here: BEGIN:VTIMEZONE TZID:Canada/Eastern BEGIN:DAYLIGHT DTSTART:20070311T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT BEGIN:STANDARD DTSTART:20071105T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD END:VTIMEZONE Maybe time for an updated release?
Are you subscribed to the .ics file or do you import the .ics file into a local calendar? Also please retest with a new profile and latest Lightning 0.5pre nightly build instead of Lightning 0.3.1.
I am subscribed to the ICS file via a URL on my server (Apache + WebDAV). Not sure how to "retest with a new profile" (please send steps) or how/where to get the new XPI (URL pls?). Thanks.
(In reply to comment #11) Marcio, Lightning 0.5 test builds are available from [http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/0.5rc2/]. To create a new profile start with command line switch -p, e.g. 'thunderbird.exe -p'.
Hello ! my problem seems to be similar: I use Sunbird on MacOSX. On start, the dates of imported events from several iCal calendars are at wrong time (2 hours early), though the event I created on a new calendar with Sunbird is at correct time red one on snapshot, on 06/28 at 14:00). To get back the correct times, I "simply" import again one of my old iCal files (on my computer), and after warning me that events are already there in Sunbird (good ! no doubles events so), all my events imported get back the correct time, not only the one I imported again. Do I create a new bug for that ? I have some snapshots of it and attached to this bug. What else do you need ?
Sorry I forgot essential information: my sunbird version is 0.5 one, using it on MacOSX.
(In reply to comment #15) > Do I create a new bug for that ? This is already filed as Bug 314339. Currently the storage provider can't store non-built-in timezone information, therefore the events are displayed wrong after restart. The import puts the timezone information back into memory, therefore the events are displayed correct.
all right ! thank you for your fast answer.
I see a similar problem with events sent from outlook 2003. Whenever a calendar event is received from Outlook (as a .ics attachment) and accepted, the event displays properly. Stopping and restarting Thunderbird causes the start and end times of that event to change to 4 hours later. The weird thing is that if I go to the calendar before exiting thunderbird and just click on the start and stop times of the event, the correct times are displayed the next time thunderbird is started. I have confirmed this problem in Lightning v0.7rc2. Sunbird v0.5 does not have this problem. Also, everyone I have spoken to at my workplace is seeing the same problem. This error is always reproducible. I am running Windows XP Professional Service Pack 2 (build 2600) and Lightning (v0.5, build 2007062404) running under thunderbird (version 22.214.171.124 (20070728))
Marking WFM based on comment 8. Some separate issues seem to have emerged, please file new bugs or comment on existing bugs if your problem still exists.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.