If I needed to define a daily alarm in a local wall clock time, I'd happily deal with a zoneless dateless hour-minute tuple and determine the alarm time by combining a date and a time using a timezone. Right after I'd convert that and handle the rest in UTC.
No, this only works for datetimes in the _past_. For future datetimes you often must store the datetime in the user's (IANA) timezone. Otherwise your application could be off. And your app could be off by more than one hour. In 2011 Samoa moved across the international date line. See https://www.theguardian.com/world/2011/dec/30/samoa-loses-da....
"Schedule a 1-1 with my boss every two weeks at 1 PM"
If you take my local time zone, convert it to UTC which puts my meeting at say 9AM UTC, schedule every two weeks at 9AM UTC and convert back to my local time zone it will be wrong when I hit change DST.
But if I instead store the (datetime, zone) pair when I say "1PM fourteen calendar days from now in zone" it will always be correct.
The UTC "trick" only works when your problem domain is representing specific moments in time.
Yes when it happens you store in UTC.
In both cases you can display to user with local timezone. (Although if the London user is going top fly to NY they will still want to see the NY time and not their local time)