> Because the vast majority of our use cases for storing timestamps is to represent specific, unambiguous moments in time, we pretty much always want to use the timestamptz type.<p>This advice is not great. One needs to specifically know their data.<p>Postgresql stores the timezone numerically, and not together with the location the timezone applies to. This means it is impossible to deduce DST from a timestamptz alone, but this is neccessary because two different locations in the same timezone might very possibly switch to and from DST at different times of the year.<p>To store an unambiguous moment in time ( e.g. when scheduling an international conference call) one can store it as a timestamptz but this doesn't gain a lot over just treating all time in the database as UTC and then converting from/to local time for input/display.<p>To store a time that is unambiguous in a certain location (e.g. a doctor's appointment in 4 months time) one needs to store it as timezone without timezone and an extra field with the locality. It makes no sense to store the timezone, unless you <i>also store the DST</i> information or unless you think you can rule out unexpected DST changes.<p>Storing timestamptz really makes a lot of sense for past events though - for example when logging.<p>So it really depends on what kind of timestamp you are trying to store, and I am not sure there is a general rule that can be applied.