You want a column that can store both timestamp and timezone, so why not just have 2 columns? You already have to convert the timestamp into the user's timezone when rendering because the user's timezone can change. Storing timestamps with timezone just complicates things, for ex:
display_in_user_zone(TIMESTAMP UTC)
display_in_user_zone(TIMESTAMP_WITH_TIMEZONE)
The above is exactly the same, but the UTC one will prevent bugs in the long run.
The only time it's acceptable to store time with timezone is with DATES that do not have a TIME component.
If you really need to display the timestamp in the timezone the user originally entered, store the original timezone along with every timestamp.
Let's say I'm writing a calendar application. Naturally, the user wants to enter all events in their own timezone, which in my case is Europe/Amsterdam. So I can just convert that to UTC, and store it along with a timezone string? Well, that's going to break horribly when the EU abolishes summer time next year, because all of those UTC stamps will be wrong!
The only sane option here is to store local time, and a string representing the timezone, which is what the name "timestamp with timezone" suggests it is. Yes, I could do the conversion manually, but it would be a lot more convenient to have it in the database directly.
Right now, supposing you have two columns, EventTime TIMESTAMPTZ and EventTimeZone TEXT, you'd have to do something like the following in your query to get the data returned to the application properly:
SELECT (EventTime AT TIME ZONE EventTimeZone) || ' ' || EventTimeZone