The Hour That Went Missing Between Two Postgres Clients

A quick sanity check after scheduling a batch of posts showed every publishedAt sitting an hour earlier than what had just been written. The instinct was to assume the write was wrong. The write was fine; the check itself was reading the same value two different ways.

Two clients, two conventions

The app writes and reads through Prisma, which treats every timestamp column as UTC on both ends, consistently, regardless of what timezone the process happens to run in. A raw pg client used only for a spot-check has no such convention — by default it parses a timestamp with no explicit zone by assuming the local one, which on this machine is UTC+1 in August.

Why this was invisible until it wasn't

The schema's DateTime column has no explicit timezone type attached, so the value stored is genuinely ambiguous outside of an agreed convention — Prisma supplies that convention every time it's the one reading, which is every time the real application runs. The gap only shows up when something other than Prisma reads the same column, which a debugging script is far more likely to do than the app ever will.

The check that actually mattered

Re-reading the same rows through Prisma showed the correct time immediately — the data had never been wrong, only one verification path through it. The lesson wasn't about timezones specifically; it was that a spot-check written in a hurry, using different tooling than the system under test, can manufacture a bug that doesn't exist and cost more trust than the five minutes it would have taken to verify with the same client the application actually uses.