Unix timestamps without seconds, milliseconds or timezone mistakes

A timestamp is an instant, not a timezone

Unix time counts from the beginning of 1 January 1970 UTC. The numeric value identifies an instant; local time appears only when software formats that instant for a timezone. Changing the display timezone should not change the underlying timestamp.

Store instants in an unambiguous representation and apply a named business timezone only at the presentation or scheduling boundary.

Detect seconds and milliseconds

Many server APIs use seconds, while JavaScript Date values use milliseconds. Passing seconds directly to a millisecond API produces a date close to 1970; multiplying milliseconds by 1000 produces a far-future date.

• Unix seconds currently use about ten digits
• Unix milliseconds currently use about thirteen digits
• Name fields with a unit suffix when possible
• Reject implausible ranges instead of silently guessing

Prefer explicit date strings

When exchanging text dates, use ISO 8601 with Z or an explicit numeric offset. A local-looking value such as 2026-09-01T09:00:00 has no offset and may be interpreted in the runtime's local timezone.

Date-only values such as a birthday are not instants. Model them as calendar dates instead of forcing them through midnight in a timezone.

Test daylight-saving boundaries

Scheduling systems need cases around daylight-saving gaps and repeated local hours. Compare the stored instant, the intended named timezone and the displayed local value, especially when a user edits an existing schedule.