‹ BackHN Continuity

Thread

Footguns with Postgres “at time zone 'UTC'”

169 points · 114 comments · birdculture

  1. heurekamala · · focus · HN ↗
    The text says: "Comparing a timestamp and timestamptz will always result in false."

    That is wrong. Postgres changes the timestamp to timestamptz very quietly in the background. Wether it uses the time zone of the session for this. If it is true or false depends on the TimeZone setting. This is more bad than "always false". In production with UTC it works. On a laptop of a California developer it does not work.

    Just tested:

      SET TIME ZONE 'America/Los_Angeles';
      SELECT '2026-03-01 00:00:00'::timestamp = '2026-03-01 00:00:00+00'::timestamptz; /* f   */
    
      SET TIME ZONE 'UTC';
      SELECT '2026-03-01 00:00:00'::timestamp = '2026-03-01 00:00:00+00'::timestamptz; /* t  */
    
    If you can, use Postgres 16. The double AT TIME ZONE 'UTC' thing from the text is not needed there. There you have date_add with a time zone as the third argument:

    date_add(b.month_start, interval '1 month', 'UTC')

    This adds the month in UTC and it stays a timestamptz.

    1. linasdev404 · · focus · HN ↗
      Adding a month is a footgun even without time zones. I was checking a spreadsheet against another implementation month by month and found that HyperFormula 3.4 returns Feb 28 for EDATE(Jan 31 2028, 1). Excel, Google Sheets and Numbers all return Feb 29, because 2028 is a leap year. Jan 31 + 1 month in a leap year is now a test case in anything I write that does month math.
      1. greenflux · · focus · HN ↗
        Thank you for pointing this out with HyperFormula! Appreciate you testing in various environments and sharing the results. I've confirmed the issue and submitted a PR with a fix that should be in the next release.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.