Please report any other irregularities here.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20060909 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20060909 Firefox/220.127.116.11 Alarms set to fire in the future on the current day fire when I open up Sunbird. Reproducible: Didn't try Steps to Reproduce: 1. define several events with alarms at different times for tomorrow 2. wait until tomorrow 3. open up Sunbird 4. all of the alarms will go off as soon as Sunbird opens Actual Results: All of the alarms went off as soon as I opened Sunbird. Expected Results: It should have waited until the alarms should have gone off. I had at least one "all day" event with an alarm set to "0 days before" but I'm not sure if that was part of the cause or not.
(In reply to comment #0) > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) > Gecko/20060909 Firefox/22.214.171.124 > Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) > Gecko/20060909 Firefox/188.8.131.52 > > Alarms set to fire in the future on the current day fire when I open up > Sunbird. > > > Reproducible: Didn't try > > Steps to Reproduce: > 1. define several events with alarms at different times for tomorrow > 2. wait until tomorrow > 3. open up Sunbird > 4. all of the alarms will go off as soon as Sunbird opens > > Actual Results: > All of the alarms went off as soon as I opened Sunbird. > > Expected Results: > It should have waited until the alarms should have gone off. > > I had at least one "all day" event with an alarm set to "0 days before" but I'm > not sure if that was part of the cause or not. > It happened again. This time, I had two events with alarms defined. The first even was at 11:30 (the second was later in the day). The first event alarm was set to go off 30 minutes before the event. It went off at 8:30. There were no other events scheduled, and no all-day events on that day.
(In reply to comment #0) Although I have not since experienced all alarms for the day going off when Sunbird first starts, nearly every day some alarms go off hours earlier than they should (sometimes as much as 4 or 5 hours early). I haven't yet noticed a pattern as to which alarms go off early or how early they go off.
What version of Sunbird are you using? I cannot confirm it with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061201 Calendar/0.4a1
(In reply to comment #3) > What version of Sunbird are you using? I cannot confirm it with Mozilla/5.0 > (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061201 Calendar/0.4a1 > In the "About" window, it says: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061006 Sunbird/0.3 I suspect it may have something to do with my timezone (America/Indiana/Indianapolis) and it may also have to do with events that were imported from the previous version of Sunbird.
Could you attach an export of the calendar file you are experiencing these Problems with? I cannot reproduce these Issues, I even waited a day :)
Created attachment 250586 [details] datafile from previous version of Sunbird My calendar file contained personal information, including telephone numbers, so I didn't want to post it publicly. I have attached an edited version of the file with all but one event removed. This event is one of the events for which the alarm would trigger as soon as I opened Sunbird instead of when it was supposed to trigger. This calendar file is from the previous version of Sunbird (edited in a text editor as described above). I imported the unedited version of this file into version 0.3 and encountered the problem with some of the events (they would trigger shortly after opening Sunbird regardless of their alarm definitions). It is possible that the problem occurred only with reoccurring events. When I changed the start time of the offending events, and then changed them back, the problem seemed to be fixed.
Are bug 359796, bug 359202 and bug 354055 the same? If so, should be marked duplicate. Afaik they are.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm not sure. I posted this problem with 0.3 after doing a manual import of my old calendars, so I assumed was an import problem. It corrected itself when I went in and changed the offending alarms, then changed them back (i.e. changed the start time to something different, then changed the start time back). Upon upgrading to 0.3.1 I started seeing a similar problem. Therefore, maybe it wasn't an import problem, but something else (in which case they may be the same problem). I haven't had 0.3.1 long enough to know if the same "solution" (changing the offending alarms, then changing them back) will correct my current problem. If so, we may be able to assume the problems are one in the same.
Reporter and commenters, if you (still) experience problems with alarms firing too early, please provide some exact and detailed information so we could track the problem down. The needed information is OS timzone, application timezone, date and time of event, alarm settings and exact time the alarm actually fired. If possible, please attempt this against a 0.5pre nightly build as well. If that is not possible, then we should be able to recreate the issue with the above information.
Summary: Alarms fire too early → Alarms fire too early, ignoring timezone settings
The next time I see the problem, I'll post detailed information about when the alarm appeared and when it should have appeared. Meanwhile, my OS (Win XP) timezone is set to "(GMT-05:00) Indiana (East)". The timezone in Sunbird is set to "America/Indiana/Indianapolis". Is there any way to find out what time Sunbird thinks it is? Why wouldn't Sunbird just use the system time (which doesn't seem like it would require defining the timezone separately from the system)? -Brian
OK, I saw the problem again. Sometime between 5:00pm and 7:00pm on March 4th, an alarm triggered. The event is an all-day, reoccurring event (every 2 weeks). This event wasn't set to occur until March 5th. The alarm was supposed to trigger "0 days before" the event, which I assume means that the alarm should have gone off around midnight. Let me know if I can provide additional information. I have had some luck with fixing the problem by redefining an event (for example changing the start time, saving it, then changing it back). In this particular case it will be difficult to test since the event won't occur again for two weeks.
Can you post the export of this recurring event, with minimal edititing if possible? In your previous event there was no timezone for the event and you heavily edited it judging by the newlines in it. You can also do an export of the event and mail it to me if your afraid of sharing personal info. When an event is saved in Sunbird it contains a DTSTART and DTEND like this: DTSTART;TZID=/mozilla.org/20070129_1/Europe/Amsterdam:20061205T220000 DTEND;TZID=/mozilla.org/20070129_1/Europe/Amsterdam:20061205T230000 Though the event you posted might be valid, if the TZ is really lacking this will probably be the cause of the bug. Which program did you use to create the event?
Created attachment 257357 [details] All-day, reoccurring event that activates alarm early OK, here is the event in question, exported as a .ICS file. I created it by selecting the event and doing "Export Selection..." from the "File" menu. Looking at the file, I see no timezone information stored. I also can't tell if it exported all occurrences of this event, or only this occurrence (I suspect the latter since there is no option to select all occurrences of a repeating event). The only program I have ever used to create events is Sunbird. This event was created in Sunbird 0.2 and imported into Sunbird 0.3 (which was subsequently updated to Sunbird 0.3.1).
Attachment #250586 - Attachment is obsolete: true
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN BEGIN:VEVENT CREATED:20070305T140614Z LAST-MODIFIED:20070305T140614Z DTSTAMP:20070305T140614Z UID:b0a4cb4a-7918-11d9-953e-b5784c3e82b7 SUMMARY:AEI Timesheet Due STATUS:CONFIRMED CLASS:PRIVATE RECURRENCE-ID;VALUE=DATE:20070305 DTSTART;VALUE=DATE:20070305 DTEND;VALUE=DATE:20070306 END:VEVENT END:VCALENDAR The event you provided doesn't have alarm-information? Also, the times are floating without timezones, so I'm guessing this is an event created in SB0.2. If you'd create a new event you shouldn't experience these problems. Also, editing such event, i.e. change something in the description, might fix this problem.
Maybe I'm misinterpreting it, but doesn't the Z after the date/time mean that it's Zulu (GMT)? I agree that there is no Z after the RECURRENCE-ID, DTSTART, or DTEND DATE values, so it's difficult to know exactly when that date starts. Is it local time zone? Zulu? In Honolulu, it would start and end half a day later than it would in London.
(In reply to comment #17) > I agree that there is no Z after the RECURRENCE-ID, DTSTART, or DTEND DATE > values, so it's difficult to know exactly when that date starts. Is it local > time zone? Zulu? If there's nothing specified (neither UTC (zulu) or anything else) it means that it's "floating", i.e. no specific timezone.
Created attachment 258906 [details] Same event exported after editing the title OK, here's the same event after modifying the title (then changing it back). Indeed it now contains more information, including the timezone. Yes, this event was imported from 0.2. -Bri
Now the event looks correct as far as i can see, if you set an alarm for this event it should fire at the correct time. I only started using sunbird/lightning after the 0.3 launch, so I don't know the exact history of the in- and exporting of the 0.2 branch. Mayve someone else can shed some light on this...
Attachment #258906 - Attachment mime type: text/calendar → text/plain
(In reply to comment #7) > Are bug 359796, bug 359202 and bug 354055 the same? If so, should be marked > duplicate. Afaik they are. Given that my problem appears to be an import problem from version 0.2 as I originally suspected, it's possible that bugs 359202 and 354055 are not the same as this bug. Those who posted those bugs should attempt to export the events in question and see if they contain timezone information.
This also occurs with Outlook appointments. As I've stated previously, in my case, this makes Lightning unusable and therefore, I have to go back to using Outlook. Kevin
Kevin, as we set bug 359202 as duplicate of this one, could you also post one of the problematic events? As you state yourself, the event is probably correct but it in a different timezone. I hope the dialogs will get a picker for choosing timezone's per event (with a default for the application timezone)...
I suspect the problem isn't that the events have the wrong timezone, but that when imported, they have no timezone (see my first attachment above). It appears that either the events need to be assigned a timezone when imported, or the program needs to handle timezoneless events better. So, why doesn't the program just use the system's time/date/timezone information?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/20070328 Calendar/0.5pre Ok, got the problem and a backup of the ics. BEGIN:VEVENT CREATED:20061011T102054Z LAST-MODIFIED:20070329T211522Z DTSTAMP:20051008T150310Z UID:b6fe14de-380c-11da-bb25-ca5b5478cc85 SUMMARY:* <Name> STATUS:CONFIRMED CLASS:PRIVATE RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=3 DTSTART;VALUE=DATE;TZID=/Mozilla.org/BasicTimezones/GMT:20060330 DTEND;VALUE=DATE;TZID=/Mozilla.org/BasicTimezones/GMT:20060331 X-MOZILLA-ALARM-DEFAULT-LENGTH:1 CATEGORIES:Geburtstag X-MOZILLA-ALARM-DEFAULT-UNITS:days X-MOZILLA-RECUR-DEFAULT-UNITS:years X-MOZILLA-LASTALARMACK:20060329T091923 BEGIN:VALARM TRIGGER;VALUE=DURATION:-P1D X-MOZ-LASTACK:20070329T211522Z DESCRIPTION:Mozilla Alarm: * <Name> ACTION:DISPLAY END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20061011T102054Z LAST-MODIFIED:20060329T071923Z DTSTAMP:20051008T150310Z UID:b6fe14de-380c-11da-bb25-ca5b5478cc85 SUMMARY:* <Name> STATUS:CONFIRMED CLASS:PRIVATE RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=3 DTSTART;VALUE=DATE;TZID=/Mozilla.org/BasicTimezones/GMT:20060330 DTEND;VALUE=DATE;TZID=/Mozilla.org/BasicTimezones/GMT:20060331 X-MOZILLA-ALARM-DEFAULT-LENGTH:1 CATEGORIES:Geburtstag X-MOZILLA-ALARM-DEFAULT-UNITS:days X-MOZILLA-RECUR-DEFAULT-UNITS:years X-MOZILLA-LASTALARMACK:20060329T091923 BEGIN:VALARM TRIGGER;VALUE=DURATION:-P1D DESCRIPTION:Mozilla Alarm: * <Name> ACTION:DISPLAY END:VALARM END:VEVENT The alarm should have fired the first time I started Calendar today, but it was the the second time iirc. Th first time, I had already four alarms (two for tasks, two for events).
This time the alarm fired too late. Yesterday evening 8pm, I updated Sunbird to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/20070417 Calendar/0.5pre and had it open until 12:30am tonight. The alarms should already have fired at mignight. The computer was hibernated and used again since 7:30am. From 11:20am to 1:20 I was away, but Calendar had fired the alarms for the event and the task. BEGIN:VEVENT CREATED:20061011T102054Z LAST-MODIFIED:20060419T092351Z DTSTAMP:20051009T161557Z UID:07acac3c-38e0-11da-9ef0-c717d65078fd SUMMARY:* John Doe STATUS:CONFIRMED CLASS:PRIVATE RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=4 DTSTART;VALUE=DATE;TZID=/Mozilla.org/BasicTimezones/GMT:20060419 DTEND;VALUE=DATE;TZID=/Mozilla.org/BasicTimezones/GMT:20060420 X-MOZILLA-ALARM-DEFAULT-LENGTH:1 CATEGORIES:Birthdays X-MOZILLA-ALARM-DEFAULT-UNITS:days X-MOZILLA-RECUR-DEFAULT-UNITS:years X-MOZILLA-LASTALARMACK:20060419T112351 BEGIN:VALARM TRIGGER;VALUE=DURATION:-P1D DESCRIPTION:Mozilla Alarm: * John Doe ACTION:DISPLAY END:VALARM END:VEVENT BEGIN:VTODO CREATED:20061102T225221Z LAST-MODIFIED:20070317T120012Z DTSTAMP:20070317T120012Z UID:eb2da856-bb46-11da-9eaa-b69ec7a4ade6 SUMMARY:Bücher fällig (give back books) PRIORITY:0 CLASS:PUBLIC DTSTART;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070423T090000 DUE;TZID=/mozilla.org/20070129_1/Europe/Berlin:20070423T180000 X-MOZILLA-ALARM-DEFAULT-LENGTH:7 LOCATION:Library URL:http://www.example.com/index.html DESCRIPTION:Book A # Author A\nTitel A # Book B # Author B\nTitel B CATEGORIES:Bibo: Freiberg X-MOZILLA-ALARM-DEFAULT-UNITS:days X-MOZILLA-LASTALARMACK:20061006T000012 X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for STATUS property. Removing entire property: BEGIN:VALARM TRIGGER;VALUE=DURATION:-P5D X-MOZ-LASTACK:20070315T191650Z DESCRIPTION:Mozilla Alarm: Bücher fällig (give back books) ACTION:DISPLAY END:VALARM END:VTODO
(In reply to comment #26) Archaeopteryx, can we clear the QAWanted flag on this problem? It looks like you successfully found the test case above with this ICS. However, I have to ask where you got the "/Mozilla.org/BasicTimezones/GMT" TZID from.
The BasicTimezones occurs mainly in german calendars. Seeing http://stuff.mit.edu/afs/sipb/project/mozilla/src/mozilla/calendar/libxpical/oeICalContainerImpl.cpp and moving up the directory, you see it's contained in libxpical. If I see this correctly, this is a file created by the suse-linux package (explains the mainly german calerdars) and was written by Mostafa in 2004. Did libical grow out of this?
The events were created using Sunbird 0.2 for WinXP iirc, for the task I'm not sure, probably Sunbird 0.3 for WinXP. Removing qawanted
I am using lightning 0.5. Upon accepting the following recurring invitation, the alarms for all subsequent events fired immediately BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2007 VERSION:2.0 BEGIN:VTIMEZONE TZID:Eastern Standard Time BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Bob :MAILTO:email@example.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Jan :MAILTO:firstname.lastname@example.org DESCRIPTION:When: Occurs every Tuesday effective 5/15/2007 from 1:30 PM to 3:00 PM (GMT-05:00) Eastern Time (US & Canada).\nWhere: Paris \n\n*~*~*~*~*~*~*~*~*~*\n\n\n\n RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TU;WKST=SU SUMMARY:Engineering Meeting DTSTART;TZID=Eastern Standard Time:20070515T133000 DTEND;TZID=Eastern Standard Time:20070515T150000 UID:0000000000000000000000000000000044284ad300002f7800000b6f00000497 CLASS:PUBLIC PRIORITY:5 DTSTAMP:20070820T170417Z TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:26 LOCATION:Paris X-MICROSOFT-CDO-APPT-SEQUENCE:26 X-MICROSOFT-CDO-OWNERAPPTID:-1 X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INSTTYPE:1 BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT15M END:VALARM END:VEVENT END:VCALENDAR
How does this work with the latest nightly which has support for foreign timezones?
This now works for me with storage calendars. I haven't old Sunbird 0.2 ics calendars anymore.
(In reply to comment #22) > This also occurs with Outlook appointments. As I've stated previously, in my > case, this makes Lightning unusable and therefore, I have to go back to using > Outlook. > > Kevin > FYI all - the sooner this fix is verified and published, the sooner I can move back to Thunderbird / Lighting a viable option and the sooner I can break free from Outlook :-) Unfortunately, consistently missing appointments can be a career limiting move and I'm not willing to risk that. Kevin
Does anyone still see this problem?
Lightning seems to work OK now
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
I still experienced problems that seem to be timezone-related, with an alarm showing up 3 hours after schedule. After reading the comments here, I tried exporting to .ics and looking at the DTSTART field. All the times were 'floating' (no timezone defined). I went to the properties and saw that thunderbird didn't know what the timezone is (even though the OS seems to define it correctly). I defined the timezone in the preferences and created a new event with an alarm, then exported an ics again. Still the timezone in the ics is not defined. I exited t-bird, opened it again, created a new calendar, created a new event, and exported to ics. Only now did the ics show the timezone. And indeed, now the alarm went off at the right time. So I suspect that these bugs are present: 1. Lightning doesn't always detect the timezone correctly from the OS. 2. when Lightning doesn't know what the timezone is, it doesn't prompt the user to get it. 3. specifying the timezone in the preferences only affects events in calendars that were created after the timezone has been specified. This is with thunderbird 14 and Lightning 1.6 on Linux 2.6.28.
Regarding my previous comment, I should note that my timezone is GMT+3, so it makes sense that the alarm showed up 3 hours late when lightning was unaware of the timezone.
You need to log in before you can comment on or make changes to this bug.