timezone-reviewlisted
Install: claude install-skill sriptcollector/toolbay-skills
# Timezone Review
## Install
Save this file as `~/.claude/skills/timezone-review/SKILL.md`, or
`.claude/skills/timezone-review/SKILL.md` to scope it to one repo. Claude Code
auto-discovers it. Invoke with `/timezone-review` or by asking "will this break
for users in other timezones?".
## Why this exists
Timezone bugs pass every test, because the test machine, the developer, and the
CI runner are usually all in UTC or all in the same offset. They appear in
production for the subset of users whose local day boundary is not yours, and
they appear as complaints that sound impossible: "my streak reset a day early",
"the report shows yesterday's number", "my subscription expired at 7pm".
They are also seasonal. Code that is correct in January can break in March when
a DST transition creates a day with 23 hours, or a local time that does not
exist at all.
The root cause is nearly always the same: **a calendar date and a true instant
are different types, and the code uses one where it means the other.**
## Step 1: Separate instants from calendar dates
Go through every date field in the schema and classify it:
**INSTANT.** A specific moment on the global timeline. `created_at`,
`last_login`, `paid_at`. Correct storage is UTC with an offset
(`timestamptz`, epoch millis). Rendering is per-viewer.
**CALENDAR DATE.** A day as humans name it, with no time and no zone.
`birth_date`, `invoice_date`, `holiday`. Correct storage is a `date` type or a
string. Attaching a time to these