Unix Timestamp Converter

About this Unix Timestamp Converter

The Unix Timestamp Converter works with Unix time measured in seconds since 00:00:00 UTC on 1 January 1970. It can translate a numeric timestamp into readable local and ISO dates or turn a selected local date-time into Unix seconds.

Unix timestamps are used throughout databases, APIs, log files and programming languages specifically because a single number is easier to store, compare and calculate with than a formatted date string, but that same compactness makes them unreadable to a human without a conversion step like this one.

For related tasks, try Date Difference Calculator, Time Zone Offset Converter or Day of Year Calculator.

How to use it

1. Enter a Unix timestamp or choose a date and time.
2. Select the direction of conversion.
3. Review the timestamp, local rendering and ISO representation.

Practical example

Unix timestamp 0 represents 1 January 1970 at 00:00:00 UTC. A later timestamp increases by one for each elapsed second.

The timestamp 1735689600 converts to 1 January 2025 at 00:00:00 UTC, and multiplying it by 1000 would give the equivalent millisecond-based timestamp some JavaScript APIs expect instead.

Things to double-check

A common source of confusion is that some systems use Unix time in seconds while others, particularly JavaScript's own Date.now() and many web APIs, use milliseconds. A timestamp from a millisecond-based system will look like a date far in the future if treated as seconds without first dividing by 1,000.

What a Unix timestamp is

A Unix timestamp counts the seconds since 00:00:00 UTC on 1 January 1970, called the epoch. The value 0 is that moment, and 1,800,000,000 falls on 15 January 2027 at 08:00:00 UTC. Ten digit timestamps are in seconds and thirteen digit timestamps are in milliseconds, which JavaScript uses. Mixing them up gives dates in 1970 or in the far future, so check the length when a date looks wrong.

Time zones and display

A timestamp is the same moment everywhere. It has no time zone; the zone only matters when you display it as a calendar date. The same timestamp can show as different local times in Karachi and London. Store and exchange times as UTC timestamps or ISO 8601 strings with an offset, and convert to local time only at the point of display. This avoids errors when clocks change.

The year 2038 problem

Systems that store the timestamp as a signed 32 bit integer can only reach 2,147,483,647, which is 19 January 2038 at 03:14:07 UTC. After that the value overflows. Modern systems use 64 bit integers, which last for billions of years, but old embedded devices and file formats may still be affected. If you design a database, use a 64 bit type or a native date type.

Debugging with timestamps

Developers convert timestamps while reading logs, API responses, cookies and tokens. JSON Web Tokens use them for expiry. When you compare two events, subtract the timestamps to get the interval in seconds. Remember that Unix time ignores leap seconds, so it is not a perfect count of elapsed seconds. For most applications this makes no difference.

Converting in code

Most languages provide simple conversions. In JavaScript, new Date(timestamp times 1000).toISOString() converts seconds to a date, and Date.now() returns milliseconds, so divide by 1000 and round down for seconds. In Python, datetime.fromtimestamp with a UTC time zone does the same. Use the UTC form when you store or send times, and apply the user's time zone only for display. When a result is off by exactly three or four digits of magnitude, a seconds and milliseconds mix-up is the usual cause.

Worked examples

A timestamp of 1,700,000,000 is 14 November 2023 at 22:13:20 UTC, and 1,800,000,000 is 15 January 2027 at 08:00:00 UTC. Midnight at the start of 7 October 2026, UTC, is 1,791,331,200, found by counting 20,733 days since 1 January 1970 and multiplying by 86,400 seconds. The difference between the last two is 8,668,800 seconds, which is 100 days and 8 hours. You can use such round numbers to check a tool or a program, and the converter shows the date for any value you enter.

Seconds, milliseconds and code

Timestamps come in different units. A 10 digit number is usually in seconds, while a 13 digit number is in milliseconds, which JavaScript uses with Date.now(). To convert milliseconds to seconds, divide by 1,000 and drop the decimals, and to create a date from seconds in JavaScript, multiply by 1,000 first. Some systems use microseconds or nanoseconds, with 16 or 19 digits. If a date comes out in 1970 or in the year 50,000, you have the wrong unit. Check the number of digits before you convert.

Storing and displaying time

Store timestamps and dates in UTC, and convert to the user's time zone only when you show them. ISO 8601 strings, such as 2026-10-07T00:00:00Z or 2026-10-07T05:00:00+05:00, state the offset explicitly and sort correctly as text. Avoid storing local times without a zone, because daylight saving makes some local times ambiguous or missing on the days the clocks change. Databases usually have a timestamp type with time zone support, and using it avoids a whole class of errors.

Debugging with timestamps

Timestamps appear in logs, tokens, cookies and cache headers. A JSON Web Token has an exp claim, the expiry time as a timestamp in seconds, and comparing it with the current time shows if the token has expired. A cookie's lifetime may be given as a number of seconds. Negative timestamps represent dates before 1970. Systems that use an unsigned 32-bit integer can run until 2106, while signed 32-bit systems overflow in January 2038. When you compare times from different servers, remember that their clocks may differ slightly, so allow a small tolerance.

Key terms explained

A Unix timestamp counts the seconds since 1 January 1970 at 00:00:00 UTC, called the epoch. UTC is the world reference time. A time zone offset is the difference from UTC. ISO 8601 is the international format for dates and times. A millisecond timestamp has 13 digits. Leap seconds are occasional adjustments to UTC that Unix time ignores. The year 2038 problem affects systems that store the count in a signed 32-bit integer.

Rules of thumb and quick checks

A day is 86,400 seconds, so add that to move to the next day. A 10 digit timestamp is in seconds and a 13 digit one is in milliseconds. 1,000,000,000 is 9 September 2001, and 2,000,000,000 is 18 May 2033. Store times in UTC and convert only for display. If a date shows 1970, the value may be zero or in the wrong unit. Allow for small clock differences between servers.

Quick reference and sanity checks

A Unix timestamp counts the seconds that have passed since midnight UTC on 1 January 1970, so the value 0 is that exact moment and 1,000,000,000 is 1:46:40 UTC on 9 September 2001. Ten digits normally mean seconds and thirteen digits mean milliseconds. If a converted date lands in January 1970, you probably gave seconds to a tool that expected milliseconds, and if it lands thousands of years ahead, the reverse is true. Timestamps have no time zone of their own, so the zone matters only when you display the date. When you save a time in a database or log, keep the raw timestamp or an ISO 8601 string with the offset, and convert to local time only for readers.

Frequently asked questions