Alarm server issues

All session alarm settings are lost when the system time is changed. The sessions are notified to calculate the time of their next alarm, and it is up to the client to do this. The client may keep the alarms at the same time with respect to the system time, it may change the alarm times to occur at the time it would have if the system time had not been changed, or it may change the alarm time to suit some other requirement.

If an alarm is queued in the past, it is sent for immediate notification. This allows the client to immediately set another alarm. The list of review alarms is also cleared to prevent the same alarm appearing twice in the review list when the time is changed backwards.

The way in which the alarm server responds to daylight saving time (DST) changes depends on the method used to change the time.

If the DST is changed through the daylight savings time zone, e.g. the Summer times dialog in the Time application, then the alarm server will clear its pending alarm queues and get its sessions to send their next alarm. If time is changed forward, alarms set for the intervening period will not be set. If time is changed back, the same alarm will be repeated.

If the time is manually changed to reflect the changeover to/from DST, this is an ordinary change in system time. The alarm server does not clear its pending alarm queues. If time is changed forward, any alarm set for the intervening period will be sent for user acknowledgement immediately. If time is changed back, there is a period (until time "catches up") when no alarms are due.

There is a limit to the number of alarms kept in the awaiting acknowledgement list—which prevents a build up of alarms when the user is not present to acknowledge them. This list can contain 8 alarm entries.

The server has been designed to reduce the chance of alarm notification’s failing due to an out of memory error. Memory for an alarm setting is allocated when a client connects to the server. This guarantees that the server can set the alarm, so long as the client is connected—the memory is de-allocated when the client disconnects.

Any session can set any number of orphaned alarms. When an alarm is orphaned, memory is allocated for another session alarm. The process of orphaning an alarm can therefore fail due to lack of memory.