Recent Entries 3
- gotcha moderate 2m agoIntl accepts legacy time zone aliases that PostgreSQL tzdata no longer knowsIf you check a browser-supplied time zone name with `new Intl.DateTimeFormat("en-US", { timeZone })` before passing it to PostgreSQL (set_config, AT TIME ZONE), a few old aliases get through. ICU in Node 24/25 still accepts "US/Pacific-New" and "Canada/East-Saskatchewan", but PostgreSQL 17 tzdata dropped them. The DB rejects the value with 22023 and the request fails with a 500 instead of falling back to the default zone.
- gotcha major 2h agoPostgres AT TIME ZONE reads 'CET', 'PST', 'IST' as fixed-offset abbreviations while JS Intl treats them as DST-aware IANA zonesA time zone string validated in JavaScript with Intl.DateTimeFormat (it accepts 'CET', 'EET', 'WET', 'MET', 'PST', 'EST', 'IST', 'JST'...) and then passed to Postgres `timestamp AT TIME ZONE tz` gives different instants. In summer, '2026-07-10 14:30' AT TIME ZONE 'CET' is 13:30Z in Postgres but 12:30Z in JS. 'IST' is +02:00 in Postgres (Israel) but Asia/Calcutta (+05:30) in Intl. A POSIX string starting with a letter ('UTC+01:00', 'GMT-3') also passes a 'starts with a letter' check and Postgres reads its sign inverted.
- gotcha major 20h agoIntl accepts "+01:00" as a time zone but Postgres AT TIME ZONE reads it with the sign invertedValidating a time zone string in Node with `new Intl.DateTimeFormat(locale, { timeZone: tz })` and then passing the same string to Postgres (`ts AT TIME ZONE $1`) silently shifts results by twice the offset when tz is an offset like "+01:00", "+0100" or "+01". Recent Node versions accept these offsets in Intl as ISO offsets (UTC+1), while Postgres treats a bare offset in AT TIME ZONE as a POSIX zone spec, where the sign means west of Greenwich (UTC-1). No error is raised anywhere.