Footguns with Postgres "at time zone 'UTC'"

Commenters wrestled with Postgres’ timestamp vs timestamptz behavior and the confusing dual meaning of AT TIME ZONE. heurekamala argued the article was wrong to say comparisons always fail, showing equality depends on the session TimeZone and noting Postgres 16 eases some conversions. ScanMyTerms and ForHackernews emphasized that AT TIME ZONE is a cast with opposite directions for timestamp and timestamptz and that the session TimeZone is an implicit third argument; they explained why calendar math and instant math disagree and why the double AT TIME ZONE 'UTC' pattern only works when the civil zone truly is UTC. tibbar flagged a DST-related btree ordering inconsistency as a reported bug in Postgres that’s hard to fix.

Opinion splits on best practices and type design. asah and ScanMyTerms recommend using TIMESTAMPTZ and normalizing to UTC on input, while beybol, braiamp, and globular-toast prefer storing UTC or both the user-sent value and a derived UTC to retain provenance. Macha and jokull argued timestamptz can be harmful for future human-scheduled events or overfitted advice, saltcured called the SQL standard’s naive timestamp a footgun and suggested stricter typing, and ulrikrasmussen pointed at JDBC and standard naming problems. Several commenters (epgui, heurekamala) also called out errors in the original article, underlining that subtle misunderstandings drive many of the disagreements.