> 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

> 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. This "interpret tz-less time as utc" in requires discipline to treat it counter to the default human interpretation of the data type, so is error prone. DB client libs will default to using ambiguous time types like LocalDate etc. Wouldn't recommend it.