British Columbia, Time Zones, and Postgres

B.C.’s clock change has developers panic-posting about missed appointments and cursed 9 a.m. meetings

TLDR: British Columbia’s permanent clock change could make future appointments appear an hour late or early if they were saved the wrong way. Commenters split between “keep it simple and let software handle it” and “save the human’s intended local time,” while everyone agreed meetings are about to get weird.

British Columbia deciding to stay on summer time year-round sounds simple to normal humans: no more fall clock switch. But in the comments, tech folks reacted like someone had kicked over a hornet’s nest full of calendars. The real fear? A doctor’s visit booked for 10 a.m. could suddenly show up as 11 a.m. months later if the computer saved the time the “easy” way. That sent the community into full time-is-fake mode.

The loudest divide was over where the fix belongs. One camp said, basically, “Do not get cute in the database, just save universal time and let trusted software handle the messy conversion.” Another camp fired back that future appointments are about what the person meant on the wall clock, not what the machine thought at the time. One commenter even popped in with a homemade solution and a pre-launch flex, teasing a future Show HN post like they were dropping a mixtape.

And then came the workplace panic. One person asked the question haunting every remote team: what happens to a Vancouver 9 a.m. standup when the other team is in San Francisco? Answer: probably surprise, it’s 10 now. Another warned that people who lazily picked “some random Pacific city” for server settings may be heading straight for a migraine this fall. The funniest mood of the thread was a shared realization that time zones are not a fact of nature, they’re a recurring prank by lawmakers.

Key Points

  • The article says British Columbia moved to permanent UTC-7 in 2026, creating an example of how future local-time appointments can drift when time zone rules change.
  • PostgreSQL `timestamptz` stores UTC values and uses time zone rules only for conversion during insert and query, not as preserved original local intent.
  • If tzdata is updated after future appointments are stored, querying those UTC timestamps under new rules can return a different local wall-clock time.
  • The article provides a SQL query to check whether the system’s Vancouver November 2026 offset reflects updated tzdata rules.
  • For future events where local time is authoritative, the article recommends storing local timestamp, local timezone, and a calculated UTC timestamp rather than relying only on `timestamptz`.

Hottest takes

"I shouldn’t store anything but current unix timestamps in UTC" — jedberg
"appointments during that hour where the clock goes back... are ambiguous" — ncruces
"I just need to know what happens to our 9am standups in Vancouver" — _whiteCaps_
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.