I agree about all of the comments that "what you should do" is highly dependent on what your users expect, but I will give my opinion anyway.
If you are scheduling a single event, you should be able to test the date and time the user provided to see if it's either invalid (in the spring DST transition), or ambiguous (in the fall DST transition). In the invalid case, prompt something like "sorry, that time is invalid". In the ambiguous case, prompt something like "did you mean 1:30 PDT (UTC-7) or 1:30 PST (UTC-8)?" and handle the selection accordingly.
But I'll approach your question from the use case of a recurring event, such as a daily alarm clock that fires every day at the same time. What would I expect as the user of an alarm clock?
If I schedule a daily time at 2:00 AM, but in the spring transition the clock goes from 1:59:59 to 3:00:00, I'd expect the alarm to go off right at 3:00:00. I certainly wouldn't want it to go off at 4:00:00 - that would be an extra hour. I also wouldn't want the alarm to not fire at all just because 2:00 didn't technically occur.
If I schedule a daily time at 1:00 AM, but in the fall transition the clock goes from 1:59:59 back to 1:00:00 - as a user of this alarm, I would expect it to go off on the first occurrence (the daylight time) only. Occurring twice would just be annoying.
But here we see how this illustrates needing to know your users expectations. What if I could tell my alarm clock to let me have that extra hour back? "Please Mr. Alarm Clock, I'd like to use my extra DST hour to sleep in late. Wake me up at the second occurrence of 1:00." - Now I haven't personally seen any alarm clocks that work this way, but I think you get my point.
Now maybe you're not working with alarm clocks. Maybe this is a timed wire-transfer or some other time-sensitive item. You should work through the expected logic and see what makes sense for you.
Be aware that DST rules vary drastically by time zone. The world does not do DST all at the same time. Much of it doesn't do it at all.
For additional clarity on DST behavior, see the charts in the DST tag wiki.