Store absolutely everything in UTC, do all calculations on UTC, and show in whatever timeunit the user wants. The one edge-case where user inputs a local time thats is not unique (repeated hour due to daylight savings time) can easily be solved consistently, and often is not even a problem at all.
I live in Seattle, I set a reminder on my phone one minute before new years 2021.
date --date "2021-01-01T07:59+00:00"
Thu Dec 31 23:59:00 PST 2020
Washington lawmakers are considering a bill to end daylight saving time. If it passes then new years eve 2020 will be PDT, not PST
2021-01-01T07:59+00:00 is midnight PST but it is 1:00 AM PDT and my alarm will be off by an hour.
Here's a use case: You and I are agreeing to meet at a given landmark. This could be any landmark in the United States, just to keep it simple. The user experience is: you propose that we meet at <landmark> at 4 PM tomorrow, and I agree. This happens on a website.
As far as you, me, and most of the system is concerned, the only sensible way to store that time is as a timezone-agnostic, UTC-agnostic local time: "2019-03-28T16:00". That's because, for the system to store that time as UTC, we have to know the UTC offset of every landmark in the United States at any point in time (which isn't an easy problem!) and consistently, correctly convert between UTC and that local time every time it gets displayed anyway. If we screwed up the UTC offset when we stored it the first time, we have to change the UTC time.
Now, if there's an additional constraint that you can only schedule meeting times that are actually in the future, you have to know what times constitute "the future" relative to the UTC offset of the landmark, so you don't get out of needing a comprehensive UTC offset map of the United States. But if you screw that up, you just end up putting an irrelevant or impossible meeting time in a dropdown and maybe dealing with some users attempting to time travel. Even that is a failure mode that users will somewhat understand, but most of the time it won't matter unless users are scheduling within the same time window as your UTC error.
If you stored it in UTC, you'd be screwing it up all the damn time until you fixed your UTC offsets, at which point previously-working data would be incorrect because someone would schedule a meeting 8 days out in one of those geographic regions for 6 PM and suddenly wonder how it got shifted to 5 PM for no reason.
Now, if we're scheduling a meeting online, and videoconferencing instead of traveling to the Navajo Reservation in Arizona--of course we store it in UTC. And if some of us are traveling to the Navajo Reservation[1] and some of us are dialing in from Newfoundland[2], we're all fucked anyway.
[1] The Navajo Indian Reservation spans multiple states, including Arizona. Arizona does not observe DST. The Navajo Indian Reservation does. However, inside the Arizona portion of the Navajo reservation, there is a Hopi Indian Reservation, which does not observe DST. Inside of the Hopi reservation, there is another part of the Navajo reservation that does observe DST.
[2] Newfoundland's UTC offset isn't an integer number of hours, there's an extra half hour in there. Enjoy!
I should add that where we store UTC that concerns a place, we also know/store that place in lat,long (or anything that resolves to this) and use that to show it in any timezone, to any user in any timezone, ..even in any era (yes places can change timezone).