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.

Test one instant in both supported units

Enter 1767225600 into Unix Timestamp Converter, then repeat with 1767225600000. Both should identify midnight UTC on January 1, 2026. The Local line depends on the browser's timezone; a Shanghai browser displays 08:00 for the same instant, while a UTC browser displays 00:00.

The number itself has no display timezone. Store an instant and a named timezone separately when a scheduling workflow needs both. Do not add eight hours to the stored Unix value merely to make its UTC rendering look like Shanghai time; that changes the instant rather than its presentation.

1767225600
1767225600000

ISO 8601: 2026-01-01T00:00:00.000Z
UTC: Thu, 01 Jan 2026 00:00:00 GMT
Unix seconds: 1767225600
Unix milliseconds: 1767225600000

Know the converter's unit heuristic

XXF treats numeric magnitudes below 100,000,000,000 as seconds and larger magnitudes as milliseconds. This is convenient for contemporary dates, but not a universal unit detector. Historical millisecond values near the epoch and extreme second values can be interpreted in the wrong unit.

When correctness depends on an explicit unit, normalize in the application before converting, or use an ISO string with an offset. Test invalid dates and range boundaries as well as today's examples. A date-only birthday should remain a calendar date; turning it into an instant can move the displayed day in another timezone.

• Name fields with _seconds or _milliseconds
• Use an explicit offset for exchanged date strings
• Compare the invariant UTC lines
• Treat local display and calendar dates as separate concerns