Option 1
You would store availability with 3 columns (assuming a single id col to identify a user)
availability_start, availability_end, user_id
searching based on a datetime would then be something like
select
user_id
from
availability
where
desired_datetime > availability_start
and
desired_datetime < availability_end
you may want to remove past dates depending on the functionality you want to offer. Obviously you'll need to decide how far into the future to store dates based on peoples cyclic date definitions.
Option 2
If it is always as simple as choosing individual days of the week and times for those days. You could store cyclic dates as
user_id, day_of_week, availability_time_start, availability_time_end
The start and end times need no date component to them. Searching based on a day of the week and a time would be something like
select
user_id
from
availability
where
desired_day_of_week = day_of_week
and
desired_time > availability_time_start
and
desired_time < availability_time_end
As an aside, there are libraries which assist with creating such recurring date patterns, where I work we use this (Java), there may well be RFC 2445 implementations in a language suitable to you.
If you use something like that then you won't be storing actual dates, but just the details of the recurrence patterns which won't really help you with your problem. We store these details by pretty simply taking the values from the recurrence definition and persisting them to the db one field to one column.
You could then also store the dates/times for some defined amount of time in the future and recalculate these on any changes to the recurrence definitions, this could obviously become quite a large operation depending on how many schedules people have and how far in the future you want to store data.