Utilify

Unix Timestamp Converter

Convert between Unix timestamps and human-readable dates. Supports seconds, milliseconds, and ISO 8601.

Built and maintained by Jay SooUpdated August 19, 2026

How to use Timestamp Converter

  1. 1
    Enter a value

    Type a Unix timestamp or a date string in either field.

  2. 2
    See conversion

    The other field updates live in your local time and UTC.

About Timestamp Converter

Unix timestamps — the number of seconds (or milliseconds) since January 1, 1970 UTC — are how most computers internally represent time. They are timezone-agnostic, sortable, and easy to do arithmetic on. But they are not human-readable: 1716595200 tells you nothing at a glance.

Conversion to a human date in your local timezone or in UTC is a constant need when debugging logs, working with API responses, scheduling jobs, comparing timestamps across systems, or just sanity-checking that "this happened at 9am, not 9pm." Utilify detects the magnitude automatically — values greater than 10^11 are interpreted as milliseconds, smaller values as seconds — and shows both UTC and your local timezone so you can spot timezone bugs at a glance. ISO 8601 output is also displayed for use in JSON payloads.

The seconds-versus-milliseconds distinction trips up almost everyone at some point. Unix and most backend languages count in seconds, while JavaScript's Date.now() and Java's System.currentTimeMillis() count in milliseconds — a factor of 1000 apart. A date that lands in 1970 is the classic symptom of feeding a seconds value into a milliseconds API; a date far in the future is the reverse. This converter sidesteps the guesswork by detecting the magnitude for you.

A word on the epoch and its limits. The reference point — midnight UTC on January 1, 1970 — is called the Unix epoch. Systems that stored the count in a signed 32-bit integer overflow on January 19, 2038, the well-known "Year 2038 problem"; modern systems use 64-bit values and are unaffected for billions of years. Timestamps are always anchored to UTC, which is exactly why they are reliable for comparing events across servers in different timezones.

When you do need a human-facing string, ISO 8601 (for example 2024-05-25T00:00:00Z) is the format to prefer in APIs and logs: it is unambiguous, sorts correctly as plain text, and is parseable everywhere. This tool shows it alongside the local and UTC renderings so you can copy whichever your context calls for.

How many digits is your timestamp?

The digit count is the fastest way to identify an unknown timestamp. As of 2026, current-time values look like this:

UnitDigitsExample (2026-08-19 UTC)Typical sources
Seconds101787097600Unix tools, most REST APIs, JWT exp/iat claims
Milliseconds131787097600000JavaScript Date.now(), Java System.currentTimeMillis(), Kafka
Microseconds161787097600000000PostgreSQL timestamp precision, Python datetime internals
Nanoseconds191787097600000000000Go time.UnixNano(), Rust, tracing systems

This converter auto-detects seconds vs milliseconds. For microsecond values, strip the last 3 or 6 digits; for nanosecond values, strip the last 6 or 9 — otherwise they will be misread as an absurdly far-future millisecond value.

When to use Timestamp Converter

  • Debugging log timestamps

    Convert epoch values from server logs to your local timezone to correlate with user reports.

  • API payload sanity check

    Verify expiration timestamps (exp, iat in JWTs; valid_until in API tokens) are reasonable.

  • Cron job scheduling

    Confirm a planned run time matches what you intended when expressed as epoch seconds.

Examples

Seconds → Date
Input
1716595200
Output
Sat May 25 2024 00:00:00 UTC
Milliseconds → Date
Input
1716595200000
Output
Sat May 25 2024 00:00:00 UTC

Five timestamp bugs worth knowing before they bite

  • Passing seconds where milliseconds are expected

    JavaScript Date takes milliseconds. Feed it a seconds value and you get a date three weeks after the 1970 epoch instead of today — the mirror image of the far-future dates you get passing milliseconds to a seconds API.

    new Date(1787097600)        // Jan 21 1970 — wrong
    new Date(1787097600 * 1000) // Aug 19 2026 — right
  • Believing a timestamp "is in" a timezone

    A Unix timestamp is always anchored to UTC; timezones exist only at display time. The sneaky version of this bug is converting a wall-clock datetime without an explicit zone — many libraries silently apply the machine’s local timezone, so the same code produces different timestamps on your laptop and your server.

    datetime(2026, 8, 19).timestamp()  # Python: naive datetime → interpreted in the machine's LOCAL timezone
  • Treating the year 2038 as someone else’s problem

    Signed 32-bit Unix time overflows on 2038-01-19 03:14:07 UTC. Modern 64-bit systems are fine, but 32-bit fields survive in embedded devices, binary file formats, and old protocol definitions — and any 12-year expiry you store today (certificates, licenses, long loans) already lands past the boundary.

  • Assuming Unix time counts every real second

    Unix time ignores leap seconds — clocks either repeat a second or smear it away. Differences between two timestamps can therefore be off by the leap seconds in between. Irrelevant for app logic, but do not use raw Unix-time subtraction where sub-second scientific or legal precision matters.

  • Sorting date strings that are not ISO 8601

    Formats like 08/19/2026 or 19-08-2026 do not sort chronologically as text — 04/01 lands before 12/31 of the previous year. Only ISO 8601 (2026-08-19T00:00:00Z) sorts correctly as a plain string; for everything else, sort by the numeric timestamp instead.

Frequently asked questions

Seconds or milliseconds?+

Both — the converter detects the magnitude automatically. Values greater than 10^11 are treated as milliseconds, smaller values as seconds.

Which timezone does it use?+

Both UTC and your browser's local timezone are shown for every conversion, so you can spot timezone bugs immediately.

Why did my timestamp convert to a date in 1970?+

You almost certainly passed a seconds value where milliseconds were expected, or vice versa — the two differ by a factor of 1000. A 1970 result means a milliseconds API received a seconds value.

What is the Unix epoch?+

It is the reference point for Unix time: midnight UTC on January 1, 1970. Timestamps count the seconds (or milliseconds) elapsed since then.

What is the Year 2038 problem?+

Systems that store the timestamp in a signed 32-bit integer overflow on January 19, 2038. Modern systems use 64-bit values and are unaffected.

Related tools

From the blog