Should I store tzdata on my laptop forever?

OS and runtime updates ship tzdata. Keep them current. Embedded devices that never update will be wrong after a law change even if Unix time is perfect.

Yes for instants. Pair them with an IANA id whenever you need to show a city clock or schedule a local 09:00.

Does NowZones expose Unix time?

Not as a product feature. The converter and clocks are civil. Developers can still think in instants; the pages answer human questions.

Unix time, UTC, and IANA zones

A meeting is an instant. A city clock is a decoration of that instant. Mixing the two in a database is how you get off-by-one hours after a DST weekend.

Last updated 2026-08-20 · Written by the NowZones publisher in Denmark. Offsets and DST examples use the IANA Time Zone Database via the same libraries as the city clocks. This is editorial explanation, not legal, medical, or aviation advice.

Store instants, not wall clocks

Unix time (POSIX time) is a count of seconds since 1970-01-01 00:00:00 UTC, with leap-second caveats. It has no idea whether the user is in Chicago. That is a feature: the instant is comparable worldwide.

When you persist “09:00” without a zone, you have persisted a wall clock. After the US springs forward, 09:00 Eastern is a different instant. Recurring jobs that query “hour = 9” in local time must use a zone id at runtime, not a stored integer hour.

ISO-8601 strings with an offset (2026-08-20T09:00:00-04:00) freeze the offset. ISO-8601 with a zone name is rarer in the wild; Java’s ZonedDateTime and Luxon can do it. For APIs, an instant in UTC plus a separate IANA id for display is the usual split.

Where the IANA id belongs

User profile: America/Chicago. Event: stored as UTC instant. UI: convert with the profile zone, or with a zone the user picked for that event.

Cron on a server should use UTC or an explicit zone in the scheduler (systemd, k8s CronJob). “Every day at 09:00” on a machine set to UTC is 09:00 UTC, not 09:00 for the customers in Lagos.

NowZones binds each city to one IANA id in the catalog. The ticking clock is Luxon (IANA tzdb) rendering that id. We do not store Unix time in the page HTML; we format a civil time for the current instant.

Classic bugs

Serialising JavaScript Date as a locale string and parsing it elsewhere. Date is an instant; toLocaleString is a decoration. Round-trip the ISO instant.

Using getTimezoneOffset() once at signup and never again. Offsets change. Store the id.

Assuming the server’s zone is the user’s zone because both “are in the cloud.” The cloud is UTC unless you configured it otherwise.

Try the tools

Frequently asked questions

Should I store tzdata on my laptop forever?: OS and runtime updates ship tzdata. Keep them current. Embedded devices that never update will be wrong after a law change even if Unix time is perfect.
Is epoch millis OK?: Yes for instants. Pair them with an IANA id whenever you need to show a city clock or schedule a local 09:00.
Does NowZones expose Unix time?: Not as a product feature. The converter and clocks are civil. Developers can still think in instants; the pages answer human questions.