Unix Timestamp Converter

A Unix timestamp converter turns the long numbers you find in logs, databases and API responses into readable dates, and turns dates back into timestamps. Our free epoch converter shows the current Unix time live in seconds and milliseconds, automatically detects whether a timestamp is in seconds, milliseconds, microseconds or nanoseconds, and displays the result in UTC, UK time with the correct GMT or BST, and your own time zone, along with ISO 8601, RFC 2822 and a relative time such as 3 days ago. You can also convert a date and time in any time zone to a timestamp, and copy ready-made code for JavaScript, PHP, Python and SQL. It all runs in your browser.

How to use the Timestamp converter

1. 1 Read the current timestampThe live panel at the top shows the current Unix time in seconds and milliseconds, updating every quarter of a second. Click Copy to grab either value.
2. 2 Paste a timestamp to convertEnter a timestamp in the Timestamp to date box. Leave the unit on Auto-detect and it works out whether the number is in seconds, milliseconds, microseconds or nanoseconds.
3. 3 Check the resultsSee the moment in UTC, UK time (with GMT or BST shown), your local time zone, ISO 8601, RFC 2822 and as a relative time. Copy any line you need.
4. 4 Convert a date to a timestampChoose a date and time and the time zone it belongs to, or paste a date string such as 2026-10-22T09:00:00Z, to get the Unix timestamp in seconds and milliseconds.
5. 5 Copy code for your projectOpen the code tabs for JavaScript, PHP, Python or SQL to see how to get the current timestamp and convert in each direction.

What a Unix timestamp is

A Unix timestamp, also called epoch time or POSIX time, is the number of seconds that have passed since midnight UTC on 1 January 1970, a moment known as the Unix epoch. At the time of writing it is a ten-digit number a little under 1.8 billion. Because it is a single number with no time zone, no daylight saving and no date format to argue about, it is an easy and unambiguous way for computers to record and compare moments in time.

You will find Unix timestamps in server logs, database columns, JWT tokens, cookies, file systems, analytics exports and the JSON returned by countless APIs. They make sorting and arithmetic simple: to find how long something took, subtract one timestamp from another; to find a moment 24 hours later, add 86,400. The catch is that humans cannot read them, which is where a converter comes in.

Unix time deliberately ignores leap seconds. Every day is treated as exactly 86,400 seconds long, so when a leap second is added to UTC the Unix clock effectively repeats or smears a second. For almost all business and web purposes this makes no practical difference, but it is why Unix time is not a perfect count of physical seconds since 1970.

Seconds, milliseconds, microseconds and nanoseconds

The classic Unix timestamp counts whole seconds, but many systems use finer units. JavaScript's Date.now and Java's System.currentTimeMillis return milliseconds, giving a 13-digit number. Some databases, tracing tools and Python's time.time_ns work in microseconds or nanoseconds, giving 16 or 19 digits. Feed a millisecond value into something that expects seconds and you get a date tens of thousands of years in the future; go the other way and everything lands in January 1970.

The auto-detect option looks at how many digits the number has. Up to 11 digits is treated as seconds, which covers every date up to the year 5138; 12 to 14 digits as milliseconds; 15 to 17 as microseconds; and 18 to 20 as nanoseconds. That matches how these values look for any date within a few centuries of today. If you know the unit, or you are working with very old or far-future dates, choose it from the menu to override the guess. Large microsecond and nanosecond values are handled with exact integer arithmetic, so no precision is lost before the conversion.

Negative timestamps are allowed and represent moments before 1970, so -86400 is 31 December 1969. Decimal seconds, such as 1700000000.5, are accepted too, which is how some logging tools and Python's time.time represent fractions of a second.

Time zones, GMT and British Summer Time

A Unix timestamp always refers to a single instant worldwide, but the clock time at that instant depends on where you are. The converter shows three versions side by side. UTC is the global reference used by servers and APIs. UK time follows the Europe/London zone, which is GMT, the same as UTC, in winter and British Summer Time, one hour ahead, from the last Sunday in March to the last Sunday in October. Your own zone is read from your browser's settings, which is useful if you work with colleagues or customers abroad.

Daylight saving creates two awkward cases when converting a date to a timestamp. When the clocks go forward in spring, local times between 01:00 and 02:00 in the UK simply do not exist. When they go back in autumn, times between 01:00 and 02:00 happen twice. The converter spots both: for a missing time it shows the equivalent moment after the change, and for a repeated time it shows the first occurrence and tells you the timestamp of the second. Time zone rules come from the database built into your browser, so historical changes, such as the UK staying on British Standard Time all year between 1968 and 1971, are reflected too.

ISO 8601, RFC 2822 and other date formats

Once you have the moment, you often need it in a particular text format. The converter gives you the most common ones ready to copy.

• ISO 8601, such as 2026-10-22T09:00:00Z: the international standard and the safest choice for APIs, JSON and databases. The Z means UTC; an offset such as +01:00 shows local time and its difference from UTC.
• RFC 2822, such as Thu, 22 Oct 2026 09:00:00 +0000: the format used in email headers and many RSS feeds. HTTP headers use a closely related format with GMT at the end.
• Human-readable local formats, such as Thu, 22 Oct 2026, 10:00:00 BST: best for showing dates to people, as long as the time zone is clear.
• Relative time, such as in 3 days or 2 hours ago: handy for checking at a glance whether a token has expired or a log entry is recent.

The year 2038 problem

Older systems store Unix time in a signed 32-bit integer, which can count up to 2,147,483,647 seconds. That limit is reached at 03:14:07 UTC on 19 January 2038. One second later, a 32-bit counter overflows and wraps round to a negative number, which those systems will read as December 1901. It is similar in spirit to the millennium bug, and the button labelled Year 2038 limit shows exactly when it falls.

Most modern operating systems, languages and databases already use 64-bit time, which pushes the limit billions of years into the future. The risk lies in embedded devices, old file formats, legacy databases and code that casts timestamps to 32-bit integers. MySQL's TIMESTAMP column type, for example, has traditionally been limited to 2038, while DATETIME is not. If you maintain systems expected to run for another decade or more, it is worth checking how they store dates now, while there is plenty of time to fix them.

Common uses and debugging tips

Developers most often reach for an epoch converter while debugging. A JWT that is rejected may have an exp claim in the past or an iat claim in the future because a server clock is wrong. A cookie or cache header may expire sooner than expected. A database row may show a created time an hour out because one part of the system stored local time and another assumed UTC. Pasting the raw number into the converter and comparing UTC with UK time usually reveals the problem in seconds.

A few habits prevent most date bugs. Store and transmit times in UTC, either as Unix timestamps or ISO 8601 strings with a Z or an offset, and convert to local time only when showing them to people. Be explicit about units in variable and column names, such as created_at_ms. Avoid parsing ambiguous date strings without a time zone, because different languages and browsers make different assumptions. And when you schedule something for UK customers, remember that 09:00 in July and 09:00 in December are different UTC times.

Everything on this page runs locally in your browser using the built-in Intl and Date features, so timestamps from internal logs or customer records are never sent to a server.

Examples you can copy

0              1970-01-01T00:00:00Z  (the Unix epoch)
1000000000     2001-09-09T01:46:40Z
1700000000     2023-11-14T22:13:20Z
2000000000     2033-05-18T03:33:20Z
2147483647     2038-01-19T03:14:07Z  (32-bit limit)

Seconds        1700000000
Milliseconds   1700000000000
Microseconds   1700000000000000
Nanoseconds    1700000000000000000

1 minute    60
1 hour      3,600
1 day       86,400
1 week      604,800
30 days     2,592,000
365 days    31,536,000

Common mistakes to avoid

Frequently asked questions