nextOcc bug: Events don't load due to js error

[Julian Piatek]

I just installed this addon, as webdav support for my exchange server was terminated, and I have been having problems getting the events to come up. The error I get is due to the following line (369) in soapin.js

    aItem.setProperty('X-MOZ-SNOOZE-TIME-' + nextOcc.recurrenceId.nativeTime,
      nextRem.icalString);

I get the error that nextOcc is null.

I had originally supposed this was due to some older items which had not been correctly dismissed or something like that, but I have now completely removed old items and still no luck.

Essentially, no calendar entries show up and ones I add in the thunderbird do not show up either. If I comment out this particular line of code everything works fine.

--
Windows 7 x64
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2

[Holger Goetz (holgerg)]

Hi,

Think this is calendar content dependent. It doesn't happen if it's "Day" view and you press the "today" - but in all other views in my calendar it happens.

Looked at the code around the offending line in soapin.js bit closer -

The nextOccurrence is calculated from the previousOccurrence if there's a difference. There are cases when there's no PrevisousOccurrence available thus the code is ending up w/ a nextOcc==null.

Could it be that the nextOccAlarm.compare call does only return "0" or "1" - and not "-1" or "0" or "1" ??
At least there isn't a check if a previous occurrence does exist at all.

Adding a "if (nextOcc === null) { }" the call to aItem.setproperty avoids the error and make things work better.

Not sure if that's really the root cause here, but maybe a point to start looking further into it.

--------- code from soapin.js - readDismissSnoozeState proc-----------

let alarmDiff = nextOccAlarm.compare(nextRem);
if (alarmDiff > 0) {
  sdbg("readDismissSnoozeState: alarmDiff>0\n");
  /*
  * The alarm of the next item will happen after
  * the remider time. This means we did snooze
  * a previous alarm.
  */
  nextOcc = aItem.recurrenceInfo.getPreviousOccurrence(nextRem);
}

if (nextOcc === null) {
  // would lead to an error otherwise
  sdbg("readDismissSnoozeState: dkipping Set X-MOZ-SNOOZE-TIME\n");
  return
} else {
  aItem.setProperty('X-MOZ-SNOOZE-TIME-' + nextOcc.recurrenceId.nativeTime, nextRem.icalString);
}

[Simon Schubert (corecode)]

Not sure if this is the correct fix - why would aItem.recurrenceInfo.getPreviousOccurrence(nextRem) return null?

Can we get a log to see which events are processed? I have a hunch that we're somehow missing one occurence.

[Holger Goetz (holgerg)]

Is a first occurrence handled differently? No previousOcc would be true for the first one in a row.

[Simon Schubert (corecode)]

Yes, but why would the snooze timer set for such an even?

[Holger Goetz (holgerg)]

Hi Simon,

bit of log info here...
Just above the if (!aItem.recurrencInfo) {} I've added a sdbg line that prints out the "nextRem.icalString". Also included is a sdbg statement that shows when nextOcc was null.

This is the output:
readDismissSnoozeState: nextRem.icalString = 20100903T054500Z
readDismissSnoozeState: no previous occurrence found (means nextOCC === null)

These lines must be the ones for the <CalendarItem> dumped below. That day i have 3 reoccuring events, but only this one does start 20100903 - so i'm sure i grabbed the right one. (look all ath the bottom, there are other nextRem.icalStrings which don't match.

It really seems the very first occurence gets hit - and that hasn'T a "PreviousOccurence that can be fetched, so nextOcc is set to null.

For the timezones: i'm in GMT+2 whereas the original date is GMT-6 (Mountain Std Time)

----------------cut -----------------
           <t:CalendarItem>
              <t:ItemId Id="AAMkADc2MTUyZTFmLTRkYTgtNDQ1NC1iNmE1LWVlYTY0YzJhZmRjOQBGAAAAAABJp9XcLhx6Qrxwms0wmfqNBwAGyqTTdTxTQI0s5jQLaERCAAAE89e9AABOIkmWM7JsRrJ6RLSojS6QAItWfaCWAAA=" ChangeKey="DwAAABYAAABOIkmWM7JsRrJ6RLSojS6QAItWfcDC"/>
              <t:Subject>Inviter - OOO</t:Subject>
              <t:Body BodyType="Text">When: Occurs every Friday effective 9/3/2010 until 12/17/2010 (GMT-07:00) Mountain Time (US &amp; Canada).

Note: The GMT offset above does not reflect daylight saving time adjustments.

*~*~*~*~*~*~*~*~*~*</t:Body>
              <t:DateTimeReceived>2010-08-23T02:38:12Z</t:DateTimeReceived>
              <t:ReminderDueBy>2010-09-24T06:00:00Z</t:ReminderDueBy>
              <t:ReminderIsSet>true</t:ReminderIsSet>
              <t:ReminderMinutesBeforeStart>15</t:ReminderMinutesBeforeStart>
              <t:ExtendedProperty>
                <t:ExtendedFieldURI DistinguishedPropertySetId="Common" PropertyId="34144" PropertyType="SystemTime"/>
                <t:Value>2010-09-03T05:45:00Z</t:Value>
              </t:ExtendedProperty>
              <t:ExtendedProperty>
                <t:ExtendedFieldURI DistinguishedPropertySetId="Meeting" PropertyId="3" PropertyType="Binary"/>
                <t:Value>BAAAAIIA4AB0xbcQGoLgCAAAAACAKkfZOULLAQAAAAAAAAAAEAAAAOB4NNX9FRpApjTBPAe40CY=</t:Value>
              </t:ExtendedProperty>
              <t:UID>040000008200E00074C5B7101A82E00800000000802A47D93942CB01000000000000000010000000E07834D5FD151A40A634C13C07B8D026</t:UID>
              <t:Start>2010-09-03T06:00:00Z</t:Start>
              <t:End>2010-09-04T06:00:00Z</t:End>
              <t:IsAllDayEvent>true</t:IsAllDayEvent>
              <t:Location/>
              <t:IsCancelled>false</t:IsCancelled>
              <t:CalendarItemType>RecurringMaster</t:CalendarItemType>
              <t:MyResponseType>NoResponseReceived</t:MyResponseType>
              <t:Organizer>
                <t:Mailbox>
                  <t:Name>inviter full name</t:Name>
                  <t:EmailAddress><email address hidden></t:EmailAddress>
                  <t:RoutingType>SMTP</t:RoutingType>
                </t:Mailbox>
              </t:Organizer>
              <t:RequiredAttendees>
           ...

[Simon Schubert (corecode)]

Thanks, that is very useful.

Why is alarmDiff != 0 then? The problem seems to be that this is an all day even that was created in a different time zone. The next alarm time is set correctly, but since you moved time zones, and Lightning does not deal with hours/minutes for all day events, the calculated alarm time is different from the alarm time set in Exchange.

I think your original fix is only a bandaid, and in the long run, we should try to fix this at the root, i.e.properly dealing with all day events.

What do you think: when should the alarm go off for all day events: at the time of the time zone, or at the local time?

[Holger Goetz (holgerg)]

I certainly do agree that a definded way of handling all day makes much more sense than the quick fix i've come up with - will pick the root cause and not the symtoms.
That's a good question - looking at the handling of the events - they get displayed in local time - it first would seem keeping the all-days in local time zone makes sense. But with looking to a meeting in a time zone like GMT+12 could lead to a situation where someone eg. was away his day, but comes back my day in the evening - so i could still make an appointment with that person in my evening == his morning.
Hmm -- i guess the alarm should go off as early as appropriate -- guess that's at start of original time zone day in the local-6h case and at start of local time zone day in the local+6h case.

Not the simplest solution, but the one warning when it really affects you.

[Von (von)]

I believe this bug is effecting me as well. I haven't modified the js to know for sure, and I don't see anything in the debug output that gives me a clue, but I certainly have all-day events and I'm working and living in different time zones currently. And I think my problems started when I added the all-day event (I just started with a fresh exchange account and this extension yesterday).

I'm mainly commenting because my symptoms are a little different: I don't see any events on the "Today Pane" or in the "Week" view, but others views (Day, Multiweek, Month) work fine. So it's an easy work-around, but had me really thinking everything was broken for a while and Holger's comment led me to check the other views.

[Gerhard Dittes (g-a-d)]

With me happened the same errors (Git-checkout).

I did a small workaround for that issue by just checking "nextOcc" for not being null:

if(nextOcc) {
    aItem.setProperty('X-MOZ-SNOOZE-TIME-' + nextOcc.recurrenceId.nativeTime, nextRem.icalString);
}

For now that works good enough for me (without that if statement it worked pretty much never)!

By the way: I like this software very much and I'm looking forward to seeing the new version coming out!
When can we expect it?

Thanks & greetings,
Gerhard

[Gerhard Dittes (g-a-d)]

It's me again. For the sake of completeness I just want to mention that my workaround is pretty much the same as proposed with comment #1. Anyway, when can we expect the new version? :-)

[Albert Bicchi (bicchi)]

I am running provider v0.12 and I am seeing the following:
When I look at the "Day" and "Week" views I can see the events on those views but when I switch to "Multiweek" or to the "Month" view it doesn't show any events. I am also showing the following for line 392: Error: nextOcc is null

Commenting (line: 392) aItem.setProperty('X-MOZ-SNOOZE-TIME-' + nextOcc.recurrenceId.nativeTime, nextRem.icalString);
shows the events on "Month" and "Multiweek" views.

I also tried workaround #9 by adding the following and and confirm this works for all four views.
if(nextOcc) {
   aItem.setProperty('X-MOZ-SNOOZE-TIME-' + nextOcc.recurrenceId.nativeTime, nextRem.icalString);
}

I am not sure which is the proper workaround or if there is perhaps more to it that needs to be understood before making a fix.

[Jan-Åke Larsson (jalar)]

Also running v0.12.

I have recurring events that are two-hour meetings every second Monday morning.

In week view, weeks that contain these recurring events are blank. In day view, days that contain recurring events are blank.

I have no all-day events. None.

Workaround would be to convert recurring events to single events.

[Simon Schubert (corecode)]

can you please paste a debug log?

[Jan-Åke Larsson (jalar)]

The error log says "nextOcc is null at /long/horrible/path/to/soapin.js line 392". If I read this correctly, it seems to me that something must go wrong in the assignment in line 390.

If you want a more extensive debug log, please tell me how to produce that.

[Simon Schubert (corecode)]

Please follow the instructions on the wiki.

[Jan-Åke Larsson (jalar)]

I won't post my whole calendar here, but I had a look at the values of the two compared times:

nextOccAlarm: '2011/02/21 09:15:00 isDate=0'
nextRem: '2011/02/21 08:15:00 UTC isDate=0'

This is the time of the first event in the recurring item.
These times are identical for my tz, so why indeed does the comparison give 1?

[Simon Schubert (corecode)]

Could you please post the entry that produces the problem? You can mask out all fields that are not relevant.

[Jan-Åke Larsson (jalar)]

OK, follows below.

            <t:CalendarItem>
              <t:ItemId Id="AAMkAGUyNGFlY2FiLTJiMjUtNDIyZi1hOGQ1LTgxMjkzYTIwOTBjNABGAAAAAAAIvLhxE1XXRpxK18urY2WsBwAItEkKFRbxS7a/MJ9Bo6xlAGBePWS4AAAItEkKFRbxS7a/MJ9Bo6xlAHycRe4aAAA=" ChangeKey="DwAAABYAAAAItEkKFRbxS7a/MJ9Bo6xlAHycTJ2B"/>
              <t:Subject>Veckomöte</t:Subject>
              <t:Body BodyType="Text"/>
              <t:DateTimeReceived>2011-01-17T09:29:24Z</t:DateTimeReceived>
              <t:ReminderDueBy>2011-02-21T08:30:00Z</t:ReminderDueBy>
              <t:ReminderIsSet>true</t:ReminderIsSet>
              <t:ReminderMinutesBeforeStart>15</t:ReminderMinutesBeforeStart>
              <t:ExtendedProperty>
                <t:ExtendedFieldURI DistinguishedPropertySetId="Common" PropertyId="34144" PropertyType="SystemTime"/>
                <t:Value>2011-02-21T08:15:00Z</t:Value>
              </t:ExtendedProperty>
              <t:ExtendedProperty>
                <t:ExtendedFieldURI DistinguishedPropertySetId="Meeting" PropertyId="3" PropertyType="Binary"/>
                <t:Value>BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAYwAAAHZDYWwtVWlkAQAAADQ1NjE3MzIwNTU2OTY0MjA1NDYxNjcyMDVCMjY1RTI1MjQyMzQwMjE1RDcxMzk0Nzc0NjUzNDMyNTAzNDQ2MzA0RDY4MzQzMzRENTk0MTM4MzQ1MjMyAA==</t:Value>
              </t:ExtendedProperty>
              <t:UID>4561732055696420546167205B265E25242340215D71394774653432503446304D6834334D594138345232</t:UID>
              <t:Start>2011-02-07T08:30:00Z</t:Start>
              <t:End>2011-02-07T10:30:00Z</t:End>
              <t:IsAllDayEvent>false</t:IsAllDayEvent>
              <t:IsCancelled>false</t:IsCancelled>
              <t:CalendarItemType>RecurringMaster</t:CalendarItemType>
              <t:MyResponseType>Organizer</t:MyResponseType>
              <t:Organizer>
                <t:Mailbox>
                  <t:Name>Jan-Åke Larsson</t:Name>
                  <t:EmailAddress><email address hidden></t:EmailAddress>
                  <t:RoutingType>SMTP</t:RoutingType>
                </t:Mailbox>
              </t:Organizer>
              <t:Recurrence>
                <t:WeeklyRecurrence>
                  <t:Interval>2</t:Interval>
                  <t:DaysOfWeek>Monday</t:DaysOfWeek>
                </t:WeeklyRecurrence>
                <t:NumberedRecurrence>
                  <t:StartDate>2011-02-07Z</t:StartDate>
                  <t:NumberOfOccurrences>9</t:NumberOfOccurrences>
                </t:NumberedRecurrence>
              </t:Recurrence>
              <t:FirstOccurrence>
                <t:ItemId Id="AAMkAGUyNGFlY2FiLTJiMjUtNDIyZi1hOGQ1LTgxMjkzYTIwOTBjNAFRAAiIzZ9pCPiYAEYAAAAACLy4cRNV10acStfLq2NlrAcACLRJChUW8Uu2vzCfQaOsZQBgXj1kuAAACLRJChUW8Uu2vzCfQaOsZQB8nEXuGgAAEA==" ChangeKey="DwAAABYAAAAItEkKFRbxS7a/MJ9Bo6xlAHycTJ2B"/>
                <t:Start>2011-02-21T08:30:00Z</t:Start>
                <t:End>2011-02-21T10:30:00Z</t:End>
                <t:OriginalStart>2011-02-21T08:30:00Z</t:OriginalStart>
              </t:FirstOccurrence>
              <t:LastOccurrence>
                <t:ItemId Id="AAMkAGUyNGFlY2FiLTJiMjUtNDIyZi1hOGQ1LTgxMjkzYTIwOTBjNAFRAAiIzexi46+wAEYAAAAACLy4cRNV10acStfLq2NlrAcACLRJChUW8Uu2vzCfQaOsZQBgXj1kuAAACLRJChUW8...

[Jan-Åke Larsson (jalar)]

Please note that the behaviour was the same when the very first item was still in place.

I still think the problem is in the comparison. If the times are equal, why does .compare give non-equal?

That there is no previous event gives you a problem, but the real error is in the comparison.

[Jan-Åke Larsson (jalar)]

Something is wrong with the timezones (mine: "Stockholm/Europe"), nextOccAlarm as string is '2011/02/21 09:15:00 isDate=0', but throwing it at toRFC3339 it ends up as '2011-02-21T09:15:00Z'. This should be 08:15:00Z.

Also, on one of my machines I get

Fel: Assert failed: TypeError: comp.getFirstProperty("TZID") is null
2: [calStorageHelpers.jsm:210] getTimezone
3: [calStorageHelpers.jsm:232] newDateTime
4: [calUtils.jsm -> calStorageCalendar.js:1329] cSC_getEventFromRow
5: [calUtils.jsm -> calStorageCalendar.js:1288] cSC_assureRecurringItemCaches
6: [calUtils.jsm -> calStorageCalendar.js:652] cSC_getItems_
7: [calUtils.jsm -> calStorageCalendar.js:605] anonymous

Källkodsfil: calUtils.jsm -> calUtils.js
Rad: 975

[Jan-Åke Larsson (jalar)]

Ignore that last assert error, I think it is a different problem. But I still think the tz is off.

[Simon Schubert (corecode)]

That backtrace comes from the local calendar and is not related to the Exchange provider. Maybe your system doesn't have time zones set up properly?

[Simon Schubert (corecode)]

How did you create the recurring item? It has a weird timezone setting.

[Jan-Åke Larsson (jalar)]

If not in TB/Lightning, then probably on my phone (Nokia E72, sync via Exchange).

[Simon Schubert (corecode)]

Can you try both and see how you can reproduce the issue?

[Jan-Åke Larsson (jalar)]

I now created a recurring event within TB/Lightning and got the same behaviour. Item below. The tz is GMT, but this is OK, I put the event at 9:00 in the Europe/Stockholm tz.

            <t:CalendarItem>
              <t:ItemId Id="AAMkAGUyNGFlY2FiLTJiMjUtNDIyZi1hOGQ1LTgxMjkzYTIwOTBjNABGAAAAAAAIvLhxE1XXRpxK18urY2WsBwAItEkKFRbxS7a/MJ9Bo6xlAGBePWS4AAAItEkKFRbxS7a/MJ9Bo6xlAHyc846OAAA=" ChangeKey="DwAAABYAAAAItEkKFRbxS7a/MJ9Bo6xlAHyc9vTs"/>
              <t:Subject>Test1</t:Subject>
              <t:Body BodyType="Text"/>
              <t:DateTimeReceived>2011-02-18T07:38:35Z</t:DateTimeReceived>
              <t:ReminderDueBy>2011-02-22T08:00:00Z</t:ReminderDueBy>
              <t:ReminderIsSet>true</t:ReminderIsSet>
              <t:ReminderMinutesBeforeStart>15</t:ReminderMinutesBeforeStart>
              <t:ExtendedProperty>
                <t:ExtendedFieldURI DistinguishedPropertySetId="Common" PropertyId="34144" PropertyType="SystemTime"/>
                <t:Value>2011-02-22T07:45:00Z</t:Value>
              </t:ExtendedProperty>
              <t:ExtendedProperty>
                <t:ExtendedFieldURI DistinguishedPropertySetId="Meeting" PropertyId="3" PropertyType="Binary"/>
                <t:Value>BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAADZjNDUxMjUzLTQ5NGItNGYzOC05ZjFiLTRkNzE2MWUzMTNkMAA=</t:Value>
              </t:ExtendedProperty>
              <t:UID>6c451253-494b-4f38-9f1b-4d7161e313d0</t:UID>
              <t:Start>2011-02-22T08:00:00Z</t:Start>
              <t:End>2011-02-22T10:00:00Z</t:End>
              <t:IsAllDayEvent>false</t:IsAllDayEvent>
              <t:Location/>
              <t:IsCancelled>false</t:IsCancelled>
              <t:CalendarItemType>RecurringMaster</t:CalendarItemType>
              <t:MyResponseType>Organizer</t:MyResponseType>
              <t:Organizer>
                <t:Mailbox>
                  <t:Name>Jan-Åke Larsson</t:Name>
                  <t:EmailAddress>x@x.x</t:EmailAddress>
                  <t:RoutingType>SMTP</t:RoutingType>
                </t:Mailbox>
              </t:Organizer>
              <t:Recurrence>
                <t:DailyRecurrence>
                  <t:Interval>1</t:Interval>
                </t:DailyRecurrence>
                <t:NumberedRecurrence>
                  <t:StartDate>2011-02-22Z</t:StartDate>
                  <t:NumberOfOccurrences>2</t:NumberOfOccurrences>
                </t:NumberedRecurrence>
              </t:Recurrence>
              <t:FirstOccurrence>
                <t:ItemId Id="AAMkAGUyNGFlY2FiLTJiMjUtNDIyZi1hOGQ1LTgxMjkzYTIwOTBjNAFRAAiIzaAyM2JYAEYAAAAACLy4cRNV10acStfLq2NlrAcACLRJChUW8Uu2vzCfQaOsZQBgXj1kuAAACLRJChUW8Uu2vzCfQaOsZQB8nPOOjgAAEA==" ChangeKey="DwAAABYAAAAItEkKFRbxS7a/MJ9Bo6xlAHyc9vTs"/>
                <t:Start>2011-02-22T08:00:00Z</t:Start>
                <t:End>2011-02-22T10:00:00Z</t:End>
                <t:OriginalStart>2011-02-22T08:00:00Z</t:OriginalStart>
              </t:FirstOccurrence>
              <t:LastOccurrence>
                <t:ItemId Id="AAMkAGUyNGFlY2FiLTJiMjUtNDIyZi1hOGQ1LTgxMjkzYTIwOTBjNAFRAAiIzaD7XcwYAEYAAAAACLy4cRNV10acStfLq2NlrAcACLRJChUW8Uu2vzCfQaOsZQBgXj1kuAAACLRJChUW8Uu2vzCfQaOsZ...

[Jan-Åke Larsson (jalar)]

No, this is wrong. Sorry for the confusion. Must be the phone, but I don't have time now. Later.

[Jan-Åke Larsson (jalar)]

Reproduced from the phone, see below. Tz seems to be GMT+DST.

            <t:CalendarItem>
              <t:ItemId Id="AAMkAGUyNGFlY2FiLTJiMjUtNDIyZi1hOGQ1LTgxMjkzYTIwOTBjNABGAAAAAAAIvLhxE1XXRpxK18urY2WsBwAItEkKFRbxS7a/MJ9Bo6xlAGBePWS4AAAItEkKFRbxS7a/MJ9Bo6xlAHyc846UAAA=" ChangeKey="DwAAABYAAAAItEkKFRbxS7a/MJ9Bo6xlAHyc9wbK"/>
              <t:Subject>Test3</t:Subject>
              <t:Body BodyType="Text"/>
              <t:DateTimeReceived>2011-02-18T08:18:21Z</t:DateTimeReceived>
              <t:ReminderDueBy>2011-02-28T07:00:00Z</t:ReminderDueBy>
              <t:ReminderIsSet>true</t:ReminderIsSet>
              <t:ReminderMinutesBeforeStart>15</t:ReminderMinutesBeforeStart>
              <t:ExtendedProperty>
                <t:ExtendedFieldURI DistinguishedPropertySetId="Common" PropertyId="34144" PropertyType="SystemTime"/>
                <t:Value>2011-02-28T06:45:00Z</t:Value>
              </t:ExtendedProperty>
              <t:ExtendedProperty>
                <t:ExtendedFieldURI DistinguishedPropertySetId="Meeting" PropertyId="3" PropertyType="Binary"/>
                <t:Value>BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAYwAAAHZDYWwtVWlkAQAAADQ1NjE3MzIwNTU2OTY0MjA1NDYxNjcyMDVCMjY1RTI1MjQyMzQwMjE1RDZBMzEzNzQzNjMzNTQyNzMzNDQ2MzIzNTY4MzUzMzRENTk0MTM4MzQ1MjMyAA==</t:Value>
              </t:ExtendedProperty>
              <t:UID>4561732055696420546167205B265E25242340215D6A31374363354273344632356835334D594138345232</t:UID>
              <t:Start>2011-02-28T07:00:00Z</t:Start>
              <t:End>2011-02-28T08:00:00Z</t:End>
              <t:IsAllDayEvent>false</t:IsAllDayEvent>
              <t:IsCancelled>false</t:IsCancelled>
              <t:CalendarItemType>RecurringMaster</t:CalendarItemType>
              <t:MyResponseType>Organizer</t:MyResponseType>
              <t:Organizer>
                <t:Mailbox>
                  <t:Name>Jan-Åke Larsson</t:Name>
                  <t:EmailAddress><email address hidden></t:EmailAddress>
                  <t:RoutingType>SMTP</t:RoutingType>
                </t:Mailbox>
              </t:Organizer>
              <t:Recurrence>
                <t:DailyRecurrence>
                  <t:Interval>1</t:Interval>
                </t:DailyRecurrence>
                <t:NumberedRecurrence>
                  <t:StartDate>2011-02-28Z</t:StartDate>
                  <t:NumberOfOccurrences>2</t:NumberOfOccurrences>
                </t:NumberedRecurrence>
              </t:Recurrence>
              <t:FirstOccurrence>
                <t:ItemId Id="AAMkAGUyNGFlY2FiLTJiMjUtNDIyZi1hOGQ1LTgxMjkzYTIwOTBjNAFRAAiIzaTpMdzYAEYAAAAACLy4cRNV10acStfLq2NlrAcACLRJChUW8Uu2vzCfQaOsZQBgXj1kuAAACLRJChUW8Uu2vzCfQaOsZQB8nPOOlAAAEA==" ChangeKey="DwAAABYAAAAItEkKFRbxS7a/MJ9Bo6xlAHyc9wbK"/>
                <t:Start>2011-02-28T07:00:00Z</t:Start>
                <t:End>2011-02-28T08:00:00Z</t:End>
                <t:OriginalStart>2011-02-28T07:00:00Z</t:OriginalStart>
              </t:FirstOccurrence>
              <t:LastOccurrence>
                <t:ItemId Id="AAMkAGUyNGFlY2FiLTJiMjUtNDIyZi1hOGQ1LTgxMjkzYTIwOTBjNAFRAAiIzaWyXEaYAEYAAAAACLy4cRNV10acStfLq2NlrAcACLRJChUW8Uu2vzCfQaOsZQBgXj1kuAAACLRJChUW8Uu2vzCfQaOsZQB8nPO...

[Simon Schubert (corecode)]

Well, now we know which device created the event with the wrong time zone. The one created by Thunderbird doesn't seem to be much better either.

[Jan-Åke Larsson (jalar)]

Please note that the event I created with TB/Lightning does not trigger the bug, I got this wrong.

But it does seem that the initial bug report also has an item with DST.

What do you mean, "wrong" tz, by the way. :)

[Simon Schubert (corecode)]

You said you put the event at Europe/Stockholm, but it was stored as GMT (without DST). I'd call that wrong.

[Jan-Åke Larsson (jalar)]

TB/Lightning stored the event at GMT without DST. This is wrong, but does not trigger the present bug.

My Nokia E72 stored the event at GMT with DST. This is correct, and triggers the present bug.

[Simon Schubert (corecode)]

The time zone is wrong for the phone as well, as far as I can see.

[Jan-Åke Larsson (jalar)]

The event is not stored in the local tz, but the time is correct. I scheduled it for 8:00 local time, i.e., 7:00 GMT.

[Jan-Åke Larsson (jalar)]

If you want to say that the DST spec is off, then say that.

[Jan-Åke Larsson (jalar)]

That tz spec probably is from the NITZ, come to think of it. From the network. In any case, it shouldn't cause a js error.

[Jan-Åke Larsson (jalar)]

And now, in the DST period, the events appear at the wrong time in Lightning, but the correct time on the phone.

The event is supposed to be at 10, but appears at 11. If I drag-and drop the item in Lightning on 10 o'clock, it reappears at 11. If I drag-and-drop it on 9 o'clock, it reappears at 10 in Lightning, and jumps one hour early on the phone after sync.

Creating new items work fine and these appear on the correct time.

[Brian Embry (brian-embry)]

I am still getting this error, except now on line 393 with version 0.17

[Jan-Åke Larsson (jalar)]

I am wondering (and perhaps Simon knows) whether this is a bug in Exchange provider or in Lightning itself. I mean, Exchange provider should not bug out like it does now, but perhaps the actual cause is that Lightning cannot parse the tz info from the Phone.

The tz info from the phone might be wrong, wonky or just unusual, but there is nothing I can do about that, really.

Simon, if you need more info on how the thing behaves, or want me to try something out, just let me know.

[Lari Fari (larifari77)]

Same problem here. Really annoying. The plugin would be really wonderful without this bug