Timestamp / Epoch Converter

Why Unix timestamps run infrastructure

A Unix timestamp is the number of seconds since 1 January 1970 UTC. Because it is a single timezone-free integer, it is the format of choice for logs, metrics, JWT expiry claims, database records and API responses. When you debug an incident you constantly translate between these epoch numbers and human dates to line up a log entry with a metric spike or a deploy event, and getting the conversion right is what makes a timeline trustworthy.

Convert epoch and human time instantly

This converter turns an epoch value into a readable UTC and local date and back again, all in your browser. That is invaluable when a monitoring alert reports an epoch timestamp and you need the wall-clock time, or when a token shows an exp claim you must check for expiry. It also handles both seconds and milliseconds, which is the difference that most often trips people up when a value looks a thousand times too large.

Common timestamp mistakes and how to fix them

The classic bug is mixing seconds and milliseconds: a millisecond value fed into a seconds parser lands in the year 55000, and the reverse puts you in 1970. Timezone assumptions cause the next class of errors, so store and compare in UTC and only convert to local time for display. For building the dashboards where these timestamps appear as metrics, see our Prometheus and Grafana monitoring setup guide.

Frequently asked questions

Seconds or milliseconds, how do I tell?

A 10-digit number is seconds; a 13-digit number is milliseconds. Feeding the wrong one gives a wildly wrong date.

What timezone is a Unix timestamp in?

None. It is always UTC-based seconds since the 1970 epoch, which is why it is unambiguous across systems.

What is the year 2038 problem?

32-bit signed timestamps overflow in 2038. Use 64-bit timestamps to avoid it in long-lived systems.

How do I check a JWT expiry?

The exp claim is an epoch value; convert it here and compare against the current time to see if the token is valid.