Timestamps and Time Zones in PostgreSQL (2016)

As many other comments state, the most practical advice is to just use 'timestamp' and ensure that all applications always use UTC. The only exception is user-facing appointments that are scheduled in that user's timezone which can't be converted to UTC safely. In this case, store the timezone in a separate column specifically for those rows/entities that need it.

In neither case is timezonetz useful or necessary, and will actually end up causing more bugs by converting timezones to/from the database instead of just returning the value and letting your application deal with it.

Even better for future dates than storing the timezone is storing the geographic point the appointment is at and determining the timezone when necessary - as timezone boundaries can change.

I think you misunderstood how timestamps work in PostgreSQL. Timestamptz is always saved as UTC. Only in exceptional cases where you need to store something in local time, such as a scheduled event that is not in UTC, you should use the timestamp WITHOUT TZ. This is also what well-known PostgreSQL developers recommend: https://tapoueh.org/blog/2018/04/postgresql-data-types-date-...

It's not about the storage of the value, it's the fact that PG will potentially change the value you provide compared to what's stored when using 'timestamptz'. If you use UTC and send it as UTC and request it as UTC then everything is fine but there are plenty of edge cases when using ORMs, handwritten SQL, different server timezones, or type conversions that can lead to issues on the way in and out of the database.

Having the database store anything other than what you provide is always a source of bugs.