You would still not be using "TIMESTAMP WITH TIME ZONE", and you would not use a TIMESTAMP of any kind - for a schedule, it's clearest if you have three columns

You would still not be using "TIMESTAMP WITH TIME ZONE", and you would not use a TIMESTAMP of any kind - for a schedule, it's clearest if you have three columns, for date, scheduled time, and the desired timezone in which the event is scheduled. That removes any ambiguity that when one needs to deal with these times for date arithmetic, as in the extremely common case of sorting them, the developer is forced to coerce the three values into ad-hoc UTC or TZ-aware timestamp objects in the application in order to sort them. More realistically, for an application that is storing only near future dates within a limited geographic range, you can probably get away with using UTC for storage, as that's what we did at MLB anyway, but today I would likely not give this advice.