Alarm server issues

All session alarm settings are lost when the system time is changed. The sessions are notified so they can recalculate 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, the alarm time may be changed 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 clearedto prevent the same alarm appearing twice in the review list when the time is changed backwards.

When the alarm server is restarted after the battery has been replaced, it silently discards alarms older then 59 seconds in the past.

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

If it is changed by setting or unsetting summer time for the current DST zone, then the alarm server will clear its pending alarm queues and get its sessions to send their next alarm. If the time is changed forward, alarms set for the intervening period will not be set. If the 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. This 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 notifications failing due to an out of memory error. Memory for an alarm setting is allocated when the 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.

A 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.