> What format should you use? Human readable strings for longterm storage, because when things go wonky, it’s easier to debug.

You can just use a TIMESTAMP with no TZ data. It's functionally the same as using the string but simpler because you avoid all the string handling headaches and gain the benefit of avoiding to avoid double booking and date/time functions to answer questions like "how many appointments do I have in April?".

▲

jagged-chisel 4 hours ago | parent [-]

I am willing to concede to “human readable” and dropping “string” iff queries on TIMESTAMP are producing a human readable string (I believe they are … I haven’t been in postgres in at least six weeks and details like that don’t make a lasting impression in muh brain)

	▲	mulmen 24 minutes ago \| parent [-]
		Why would queries on TIMESTAMP not produce human readable strings? Postgres has defaulted to a human readable mask for timestamp presentation for at least 25 years. Never say never but I honestly cannot imagine a situation where storing a date as a string is preferable to a native type. E: In a situation where you are processing user input (API, data file) and want to preserve exactly what was presented to your system. Arguably when processing a CSV or JSON payload there is not TIMESTAMP type so the "timestamp" is legitimately a string. The point is always choose the appropriate type. See Current: https://www.postgresql.org/docs/current/datatype-datetime.ht... And 7.1 (2001-04-13): https://www.postgresql.org/docs/7.1/datatype-datetime.html (Section 3.4.2)