I guess that you by "date" actually means "day-of-month" in your code.

A date is normally considered to point out a specific day in a calendar which means that it requires year + month + day, and not just day-of-month. Of course, a date don't need our traditional encoding with years and months - it can just as well be a sequential number like julian dates where day 0 or day 1 is given a fixed position in the almanac and all other days are just n steps higher/lower.

But another thing - your match code requires an alarm to be either "day-of-week" or wildcard. It would actually be better to store the alarms with a 7-bit mask where you have one bit for each day of the week. With a bitmap like:

enum {
    DAY_MON = 0x01,
    DAY_TUE = 0x02,
    DAY_WED = 0x04,
    DAY_THU = 0x08,
    DAY_FRI = 0x10,
    DAY_SAT = 0x20,
    DAY_SUN = 0x40,

    MASK_WEEKEND = DAY_SAT|DAY_SUN,
    MASK_WORKDAYS = DAY_MON|DAY_TUE|DAY_WED|DAY_THU|DAY_FRI,
    MASK_EVERYDAY = DAY_MON|DAY_TUE|DAY_WED|DAY_THU|DAY_FRI|DAY_SAT|DAY_SUN
};

That gives you the freedom to match any combination of days in the week. Maybe the child should be left to the daycare at one time on mondays+wednesdays+fridays, and another time on tuesdays+thursdays.

If looking at cheap lamp timers, a lot of them don't have a calendar function. That means that the super-cheap timers just mimics a mechanical 24-hour timer. The slightly better timers can mimic a one-week mechanical timer. But very good results can be had by extending a timer to span 14 days. Still no need to care about number of days in a month or leapyears or similar, and no need to have a display capable of presenting a date. Just a couple of LED to show weekday and one extra LED for "next week".

Another thing is that it is great to have a "once" flag or "max count" number for an alarm, making the alarm autmatically be disabled after having been trigged once or "max count" times. This allows an alarm to happen for the next four fridays, or a single time at 12:30 without the user needing to fully qualify the alarm with year + month + day.

A scan functition should also have a means to compact the alarm list. This needs not be done on every alarm test but at least every time the user plans to add new alarms. All alarms with a non-wildcard year less than the current year, or year+month in the past or year+month+day in the past or with a already trapped "once" flag or a zero "max count" field can be garbage-collected, reducing the number of alarms that needs to be scanned and giving room for new alarms to be added.

Another thing is that a busy-looping scan only works well if the unit is constantly powered. In the case the unit is expected to sleep (or be powered off) while the RTC counts down the time to the next alarm, then the scan code must be able to scan for future alarms, and find the alarm that will happen soonest, so that the RTC alarm function can be programmed with the next wake-up event.

The great thing with designing a lamp timer or multi-alarm clock is that it can be implemented incrementally and between each incremental step it can still be a useful product. At the same time, there are basically no limits to how much optional extras that may be added with a bit of imagination and time.

So the real work is to figure out the minimum to get anything working and try to implement that. The only thing is that such an incremental design should look a number of steps in advance when deciding on the physical interface.

How to present time (serial port, individual LEDs, 7-segment digits, LCD text panel, ...)
How should the user set time and enter alarms (serial port, buttons+LEDs, buttons+7-segment digits, keypad+LCD, ...)
How should alarms be presented (single piezo summer, single relay, multiple summers/relays/lamps/, ...)
How to keep time (processor clock crystal, counting cycles on mains power, RTC, GPS time, radio broadcasts, ...)
How should the device be powered (batteries, wall-wart, wall-wart + battery reserve, wall-wart + self-charging accumulators, usb port from PC, ...)
What way to build the unit (wire-wrap, prototype strip board, home-made PCB, ...)
What size/type of enclosure.
...

Some of the above decisions needs to be made early, since the wrong choice means a lot of rework rebuilding new hardware. But for the software part, it's very easy to start small.
- just boot and show "alive"
- updated to tick second
- updated to handle hours+minutes+seconds
- updated to get initial time from RTC and to set absolute time.
- updated to generate a single alarm at a single hard-coded time.
- updated to allow single time to be specified by user.
- updated to support year/month/day-of-month
- updated to support multiple alarms
- updated with snooze functionality and alarm repetition until acknowledged.
- updated with intelligent output activations (blink or beep sequences, timed relay activations, ...)
- ...

Note that a lot of applications using an RTC does not make use of the RTC memory cells for the second-by-second operations. They often load the time from the RTC on startup, and then use a periodic tick from the RTC (sometimes produced by interrupt output, and sometimes on dedicated square-wave output) to count time in software. This often have the advantage that the processor can perform cusom tests each second - such as updating a display, blinking a colon between hours and minutes etc.

If the device is battery operated and power consumption is extremely important, then the alarm function available in most RTC can be very valuable - just deactivating the normal interrupt/square wave pulses from the RTC and sleep the processor, waiting for an alarm interrupt from the RTC. With a fast-booting processor, it's possible to not just sleep but to turn off all power and have the RTC interrupt restore power when it's time for the alarm.