Data serialization ·
Epoch vs ISO 8601: local date-time without server clock skew
Unix epoch is a count of seconds (POSIX) or milliseconds (JavaScript Date) since 1970-01-01 UTC, ignoring leap seconds. ISO 8601 is a civil timestamp with an offset. Converting in the browser uses the local Date object or Intl. There is no server clock in the loop, which means you inherit the device clock’s skew — the same skew that breaks JWT exp.
Seconds versus milliseconds
if (n < 1e11) treat as seconds. Document it. Logs and JWT NumericDate are seconds. JS APIs are ms.
const ms = epoch < 1e11 ? epoch * 1000 : epoch;
const iso = new Date(ms).toISOString();UTC versus local
getTimezoneOffset is minutes, inverted sign relative to ISO offsets. Intl with timeZone: 'UTC' or an IANA name is less error-prone. Temporal is the future API.
Skew and JWT
If the laptop is 10 minutes slow, exp looks valid too long. Verifiers should use their clock, not the client’s. Debugging tokens still happens locally (Post 14).
Cron and DST
Civil times in cron are not epoch instants until you pick a zone (Post 15). Convert both ways when debugging a missed job.
Invalid parse
new Date('nope') is Invalid Date; getTime() is NaN. ISO without offset is interpreted as local in ES5 and as UTC in some HTML date-only forms — another reason to be explicit.
Frequently asked questions
Seconds or milliseconds?
Unix traditionally seconds. Date.now() is milliseconds. 10-digit vs 13-digit is the usual mix-up. Detect by magnitude.
Does toISOString use local time?
No. Always UTC with Z. For local, use Intl.DateTimeFormat or Temporal.PlainDateTime when available.
Do leap seconds appear in Unix time?
POSIX time smears or skips; it is not a pure TAI count. Do not build a leap-second table in a widget unless you are a time lab.