Works fine here. If I change the alarm method preference, current 
events have their alarm methods changed too.

Hi Jan

The TTL ($conf['alarms']['params']['ttl']) is set to 300 seconds. The 
non-updated events have been persistent for many days in the database 
and are not updated.

The TTL event therefore is either not functioning correctly or is not 
implemented in the way you describe.
Regards
Mark

This is nice to have, but the events are updated after the TTL anyway, 
so this is really only a short timestamp while the alarm methods are 
incorrect.

Alarms that are already set in a user's calendar are not updated when 
a new method of notification is chosen in the preferences for a user. 
For example, if notify by inline method is changed to email.

This is apparent when looking at the horde_alarms->alarm_params field 
for a pre-existing event, which still shows a notify-type alarm:
a:1:{s:6:"notify";a:1:{s:4:"show";a:3:{s:5:"__app";s:9:"kronolith";s:5:"event";s:32:"04d3e641680242abceb6b50147501ab2";s:8:"calendar";s:32:"2b0fbd8a792cacfcfd0773bbdfede050";}}}
Whereas a new kronolith calendar entry with an alarm will correctly 
set an email event:
a:1:{s:4:"mail";a:3:{s:6:"__desc";s:0:"";s:5:"email";s:18:"test@example.com";s:4:"body";s:103:"We would like to remind you of this upcoming 
event.

test

Location:

Date: 2011-04-19
Time: 04:10pm

";}}

As there is no mechanism that we are aware of to bulk-change the 
user's existing alarms other than re-creating all of them manually, 
this appears to be a bug in the system. If a user changes their 
notification from one type to another, Horde should automatically 
update the user's reminders to the chosen type.