* when an alarm is loaded into memory from an alarm file, it is validated to
  ensure that the alarm is falling into a valid day of the week
  (PROCvalidate_alarm). This is achieved by making the alarm go BACKWARDS
  until it is valid.

* when the user manipulates the alarm/clock windows,
  PROCchange_date/month/year are called as appropriate. These all work the
  same way - the five byte time is broken down into its cardinal parts, the
  appropriate cardinal is changed and the five byte time is reconsituted.

* special repeating alarms

* calculating when an alarm repeats:
  PROCincrement_alarm for normal repeating alarms - works by just adding the
  appropriate value to the appropriate cardinal. Possible problems: assumes
  adding 2 will get it into a valid day of the week.
  PROCincrement_special_alarm for special repeating alarms - works by first
  of all seeing if the alarm will go off in this month, if so, we are OK.

* the guts of this system, PROCencode_time, does assume that there are 12
  months in the year. However, if Ran implements an alternative, we may have
  a way out.

* FNvalid_day_of_week needs to know which days are working days.

* deferring alarms works like normal repeating alarms - the appropriate
  offset is added to the appropriate cardinal.

* calculating when an alarm has gone off: this works by turning the
  current five byte time into a string and then comparing that against the
  five byte time of the alarm.
