Operator timezone is not just a setup question

Mon, 01 Jun 2026 00:00:00 +0000

The operator timezone question in npm run setup looks like a small preference. It is more useful than that.

vanityURLs uses timezone names in places where a numeric offset is too brittle: scheduled links, generated registry metadata, and operator-facing views such as /en/_stats/.

Use a place, not an offset

Enter an IANA timezone such as America/Toronto, America/New_York, Europe/Paris, or UTC. Do not enter -4, -5, or GMT-0400.

An offset only describes one moment. It does not describe daylight saving time, historical transitions, or the operator’s normal working context. A place-based timezone lets the JavaScript runtime handle EST/EDT or other local transitions without the instance owner updating config twice a year.

When scheduled links are useful

Fri, 22 May 2026 00:00:00 +0000

Most short links should be boring: one slug, one destination, one clear owner. Scheduled links are for the few cases where the slug should stay stable but the destination needs to change during a predictable time window.

The starter instance includes a deliberately silly /contact example. During the configured 9-to-5 window, it can point to Dolly Parton’s “9 to 5”; outside that window, it falls back to Rick Astley and “Never Gonna Give You Up.” The point is not the music taste, heroic as it may be. The point is that one memorable short link can have a normal destination and a time-based exception.

Scheduled-Links on vanityURLs

Operator timezone is not just a setup question

Use a place, not an offset

When scheduled links are useful