Unix Timestamp Converter

Paste a Unix timestamp or a date and get every other representation, in UTC and in your own timezone. Units are detected from the digit count, and the tool tells you which one it picked, because that is the thing that goes wrong.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Convert. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

The 2038 problem

A timestamp past the signed 32-bit limit, and what still breaks on it

2147483648

Seconds against milliseconds

The same instant in both units, and how the digit count tells them apart

1700000000
1700000000000

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Reading a seconds timestamp as milliseconds

    It lands in January 1970, which looks like an uninitialised value and gets investigated as a bug rather than a unit mismatch.

    Instead:Count the digits. Ten is seconds, thirteen is milliseconds, for any date in this era.

  2. Storing a time in a signed 32-bit field

    It overflows on 19 January 2038. This is not only old C code: some databases and file formats still use it.

    Instead:Store 64-bit, and test with a date past 2038 rather than assuming.

  3. Treating a Unix timestamp as timezone-free

    It is UTC by definition, but almost every display converts to local time somewhere in the stack, which is where an off-by-hours bug enters.

    Instead:Keep UTC end to end and convert only at the point of display.

What it checks

Converting is arithmetic. Knowing whether you were handed seconds or milliseconds is the actual problem.

Units, named out loud

Ten digits is seconds, thirteen is milliseconds, sixteen is microseconds. The verdict says which reading it used, so a value that was actually in different units is visible rather than quietly producing a date in 1970.

The ambiguous lengths

Eleven and twelve digits are genuinely undecidable, and the tool says so instead of guessing confidently. Those are exactly the cases where a wrong assumption produces a plausible-looking wrong answer.

The 2038 problem

Anything past 19 January 2038 is beyond a signed 32-bit time_t, which wraps to 1901. It sounds distant and is not: a 20-year retention date set today already crosses it, and embedded devices and older MySQL TIMESTAMP columns still care.

Every format at once

ISO 8601, RFC 2822, your local time with the timezone named, relative time, seconds, milliseconds, microseconds, day of week, day of year and ISO week. No mode switching to get the one you needed.

What is a Unix timestamp?

A single number: how many seconds have passed since midnight UTC on 1 January 1970. No timezone, no calendar, no formatting, no ambiguity about whether 03/04 means March or April. That is why almost every log line, database column and API response uses one underneath whatever it displays.

Seconds or milliseconds, and how to tell

The Unix convention is seconds. JavaScript's Date.now, Java's currentTimeMillis and most JSON APIs use milliseconds. Nothing in the number itself says which, so the digit count is the tell: a ten-digit number is seconds until the year 2286, and a thirteen-digit one is milliseconds. Feeding milliseconds to something expecting seconds lands you in the year 55000, which is the classic 'expiry far in the future' bug.

1769472000      10 digits  ->  seconds       2026-01-27
1769472000000   13 digits  ->  milliseconds  2026-01-27
1769472000      read as ms ->  1970-01-21    the other direction

The 2038 problem

A signed 32-bit integer runs out at 03:14:07 UTC on 19 January 2038, and the next second wraps to 1901. Modern languages use 64-bit time and are fine, but the value still shows up in embedded systems, old database columns, file formats and protocols that fixed the width decades ago. Anything storing a timestamp in an int32 today has a deadline.

2147483647  ->  2038-01-19 03:14:07 UTC   last valid int32 second
2147483648  ->  1901-12-13 20:45:52 UTC   after the wrap

Leap seconds are quietly ignored

Unix time pretends every day is exactly 86,400 seconds long. Real UTC occasionally inserts a leap second, and rather than represent it, Unix time repeats or smears the value. This means the difference between two timestamps is not always the true elapsed time, usually irrelevant, and occasionally the reason a duration is off by a second in a system that measures precisely.

The timestamp has no timezone, the display does

A Unix timestamp is always UTC. Any local time you see is a rendering choice made at display time, which is why the same value shows two different clock times to two people. Storing local time instead of an epoch value is how you get bugs that only appear during daylight saving transitions: the hour that happens twice, and the hour that never happens at all.

More encoding tools

Base64 Encoder & Decoder Both directions, UTF-8 done right JWT Decoder & Inspector Read the claims, and what is wrong with them URL Encoder and Decoder Which of the two functions you actually want HTML Entity Encoder and Decoder Five characters, not four hundred Hex Encoder and Decoder Bytes, with a hex dump Base32 Encoder and Decoder Two alphabets that decode differently String Escape Converter Six targets, one of them injection Punycode and IDN Converter The domain that is not what it looks like

Elsewhere on the site

Terraform Validator & Formatter Kubernetes YAML Generator Kubernetes YAML Validator AWS IAM Policy Validator & Analyzer