About the Unix Time Converter
Unix time counts seconds since 1970-01-01T00:00:00 UTC — the epoch. It appears everywhere in engineering: log timestamps, JWT exp/iat claims, TLS certificate validity, cron debugging, database columns, and API payloads. This converter translates between epoch values and ISO 8601 in both directions, handling seconds and milliseconds.
The most common conversion bug is unit confusion: JavaScript's Date.now() returns milliseconds while most Unix tools and JWT claims use seconds. A timestamp that lands in the year 56000+ was almost certainly milliseconds parsed as seconds; one that lands in 1970 is the reverse.
Frequently asked questions
Is Unix time affected by time zones or daylight saving?
No. Unix time is always UTC — the same instant produces the same epoch value everywhere on Earth. Time zones only enter the picture when you format that instant for humans, which is why storing epochs (or ISO 8601 with offset) and converting at display time is the standard practice.
What is the year 2038 problem?
Signed 32-bit integers overflow at 2,147,483,647 — which as a Unix timestamp is 2038-01-19T03:14:07 UTC. Systems still storing time in 32 bits will wrap to 1901. Modern 64-bit time_t, Java/JavaScript longs, and PostgreSQL timestamps are unaffected, but embedded systems and old file formats remain at risk.
Why is my JWT rejected with an exp claim that looks correct?
JWT exp and iat are defined as seconds since epoch. Libraries that accidentally write Date.now() (milliseconds) produce tokens that appear to expire ~50,000 years from now, which strict validators reject as malformed — or clock skew between issuer and verifier of even a minute can cause valid tokens to fail; most validators accept a small leeway for this.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.