2026-09-18 · 6 min read · Rahul Chitturi
- jwt
- time
- authentication
JWT exp, nbf, and iat values use NumericDate: seconds from the Unix epoch, with non-integer values permitted by the data model. Implementations often choose whole-second precision, and producer-verifier differences around fractions can create boundary-only failures.
A milliseconds value accidentally placed in a seconds field is a different and much larger error. Identify the unit before investigating rounding or clock skew.
Preserve the original claim value
Decode a safe fixture and record the JSON number exactly before converting it to a date. Then trace parser representation, rounding, comparison operator, current-clock precision, and configured leeway in the production verifier.
- Distinguish seconds from milliseconds immediately.
- Check whether fractions are accepted, truncated, or rounded.
- Use UTC instants for diagnostics.
- Do not fix malformed units by adding large leeway.
Define boundary semantics
Document how the token profile treats fractional claims and generate values that every supported verifier handles consistently. Validate issuer, audience, signature, and algorithm as well as time claims.
Leeway should cover measured clock uncertainty and transport delay, not hide long token lifetimes. Apply it consistently and keep its security impact visible.
Create cross-runtime time vectors
Use the JWT decoder for synthetic headers and claims, timestamp converter for seconds and instants, JSON formatter for number representation, and diff for library settings.
Test whole and fractional seconds, exact expiration and not-before boundaries, negative and far-future values, milliseconds mistakes, clock movement, serialization across languages, leeway edges, malformed numbers, and every supported verifier version.