Skip to content

fix(db): parse timestamp columns as UTC regardless of server timezone#223

Merged
patrickrb merged 2 commits into
mainfrom
fix/timestamp-utc-parsing
Jul 13, 2026
Merged

fix(db): parse timestamp columns as UTC regardless of server timezone#223
patrickrb merged 2 commits into
mainfrom
fix/timestamp-utc-parsing

Conversation

@patrickrb

Copy link
Copy Markdown
Owner

Problem

contacts.datetime (and every other timestamp column) is timestamp without time zone, storing UTC by convention. node-pg's default parser interprets those values in the server's local timezone — but every sync path assumes UTC via toISOString()/getTime(): QRZ/LoTW ADIF date/time emission, both ±15-minute confirmation matchers, and the .tq8 signer. On Vercel (TZ=UTC) everything lines up; on a self-hosted box with TZ≠UTC, QSO times ship skewed by the UTC offset and confirmations stop matching.

Fix

Register a pg type parser for OID 1114 (timestamp without time zone) in getPool() that reads timestamps back as UTC (new Date(value.replace(' ', 'T') + 'Z')), and document the UTC convention at the top of drizzle/schema.ts. No behavior change on Vercel; correctness fix for self-hosted.

Verification

🤖 Generated with Claude Code

All `timestamp without time zone` columns store UTC by convention, but
node-pg's default parser interprets them in the server's local timezone.
Every sync path assumes UTC via toISOString()/getTime() — QRZ/LoTW ADIF
date/time emission, both +/-15-minute confirmation matchers, and the .tq8
signer — so a self-hosted install with TZ != UTC shipped skewed QSO times
and mismatched confirmations. On Vercel (TZ=UTC) this is a no-op.

Register a pg type parser for OID 1114 in getPool() that reads timestamps
back as UTC, and document the convention in drizzle/schema.ts.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@vercel

vercel Bot commented Jul 13, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
nodelog Ready Ready Preview, Comment Jul 13, 2026 5:20pm

Request Review

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR addresses a timezone-related correctness issue in Nextlog’s PostgreSQL access layer by ensuring timestamp without time zone values (stored as UTC by convention) are parsed back into JavaScript Date objects as UTC, regardless of the host server’s local timezone. This prevents silent time skew that breaks downstream sync/export logic (QRZ/LoTW/ADIF matching, signing, etc.) on self-hosted deployments with TZ≠UTC.

Changes:

  • Register a node-postgres type parser for OID 1114 (timestamp without time zone) in getPool() to interpret returned timestamps as UTC.
  • Document the project-wide UTC storage convention for timestamp columns in the Drizzle schema.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
src/lib/db.ts Adds a pg type parser override so timestamp without time zone is parsed as UTC instead of local time.
drizzle/schema.ts Documents the UTC-by-convention rule for timestamp columns and references the db parser behavior.

Comment thread src/lib/db.ts
node-pg's default Date serialization emits local-time strings, and
timestamp-without-time-zone columns ignore the trailing offset, so on a
non-UTC Node process Dates written by Contact.ts / adif.ts would be
stored as local wall-clock and then misread as UTC by the new parser.
pg.defaults.parseInputDatesAsUTC = true makes Date params serialize as
UTC (+00:00), which is also lossless for timestamptz columns.

Addresses Copilot review feedback on #223.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@patrickrb
patrickrb merged commit b99ab2d into main Jul 13, 2026
7 checks passed
@patrickrb
patrickrb deleted the fix/timestamp-utc-parsing branch July 13, 2026 17:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants