← ClaudeAtlas

timezone-reviewlisted

Find the date and time bugs that only appear for users in other timezones or on specific days, by separating true instants from calendar dates and checking where the server's local clock leaks in. Use before shipping scheduling, reporting, streaks, expiry, or anything with a daily boundary.
sriptcollector/toolbay-skills-claude-code-skill-pack · ★ 0 · Code & Development · score 72
Install: claude install-skill sriptcollector/toolbay-skills-claude-code-skill-pack
# 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