The problem is the way Lightning handle it. I use TB and Lightning for 
several years, and this was always a problem.

Now I'm usng TBSYNC to do add the accounts and... no more problem.

I have 14 different calendars in my GMail account. Imagine how pissed 
I've already became with TB.

TBSync always makes easy the job of syncing contacts.

It still have some bugs to use EWS for calendars, but for contacts work great.

And the main reason that I use TB, is that past appointments are not 
automatically dismissed, if not seen. If this is not a problem to you, 
if you only care about your today's appointments, then use Windows 
Calendar (if a Windows user), because it's the lightest and easier 
calendar manager that I've ever used.

I was using it until I figure out that TBSync would solve my problem.

But... Thunderbird still isn't perfect. It has problems to 
automatically add ICS to an agenda, if downloaded from a website, and 
it can't interpret several meetings invitation that come by e-mail.

I'm still have hope that someday all the problems will be fixed, but 
as I'm also a realistic person, I use Outlook and Windows Calendar to 
help me stay the best productive as possible, as TB alone can't.

Sorry to tell it, but it's true.

Maybe a profession paid version would help, and I'd be the first to 
use and to share the experience. Right now I already pay OWL EWS 
provider to enable Office365 to work with TB correctly.

And finally... why I don't use Outlook to do everything? Simple... try 
to search an important old e-mail fast in Outlook. If search function 
in Outlook was like TB search, I'm sure that I'd add all my accounts 
there.

Right now I use 3 different tools with overlap between them, unfortunately.

Good Morning, how can i not garbage-collect alarms that have been 
dismissed? I have the same problem and i want to fix it. Alarms 
dissapear if i uncheck "separate calendars" but only until next reboot.

+ 1 For the second solution

+1 For the second solution as well.

Any further votes?

I would vote for the second solution. Let the alarms stay in the db as 
long as the event is there. If one does not purge the events the 
additional alarms shouldn't matter, no? But i'm not sure how would 
this handle never ending recurrent events,  do they pile up in the 
alarm table "forever"?

I'm not sure if it is the best solution to consider all past alarms as 
dismissed, though it's definitely one solution.
Alternatively we could not garbage-collect alarms that have been 
dismissed, though these alarms will stay in the database forever, or 
at least until the connected event/task is deleted.
A third option would be to don't change anything, because there is a 
setting in Lightning to not run missed alarms. As this option exists, 
I don't think the first solution is a good idea, because it renders 
this option useless. People would never get missed alarms even if the 
explicitly ask for it.

seems like a dup of #7470

I am using horde webmail 5.1.3 with kronolith 4.1.4.
When using iCal (ICS) remote subscription on Mozilla Thunderbird 24.3 
+ Lightning 2.6.4 I keep getting random reset on previous events 
alarms status. Then all alarms from about a month back are popping up 
again.

I have investigated into the code and attached a proposed patch.
To me the problem is twofold :
- Lightning make expired alarms pop up (all dismissed alarms popping 
up are always on old events)
- Kronolith randomly "garbage collect" old events alarms and then 
doesn't keep their status

Looking at the code it randomly purges the horde_alarm table ("gc" 
function) then all informations about old alarms are lost.
When exporting again the iCal in Event class the X-MOZ-LASTACK flag is 
not for old events set since we have no more entries for them in 
horde_alarm table.
Thus Lightning considers alarms as "fresh" for old events and make 
them pop up again...

So here is a patch attached that adds X-MOZ-LASTACK for all old alarms 
even if there is no more entry in horde_alarm table to keep the 
dimissed/snooze status.
This seems to be a workaround to me since I do not understand why 
expired alarms should me notified ... (Lightning actual behavior)

Moreover, to help with broken alarm dismissal client implementations 
(or read-only access trying to update alarm status info) it may be 
helpful to add a config/pref to Kronolith in order to remove expired 
alarms for iCal export. Since iCal cannot store the status of alarm 
notification (to my knowledge after reading the RFC, that's why 
Mozilla seem to have added an extension for this) I don't see any 
other mean to get rid of past notifications.
Either way, another subscription URL or better a query string (<ics 
url>?no_expired_alarms=1) could make it configurable by the subscriber 
for each client.