Timestamp Converter

What the Converter Does

• Current Unix Timestamp at the top is the number of whole seconds since 1 January 1970, 00:00:00 UTC. It updates once a second. It comes from your device's clock, so if that clock is wrong, this number is wrong too.
• Timestamp → Date takes a timestamp in seconds, milliseconds, microseconds or nanoseconds. By default it guesses the unit from the number of digits and tells you which unit it used. It shows the date in your local time, in your browser's usual date format, and then the same moment in UTC. For 1700000000 the UTC part reads Tue, 14 Nov 2023 22:13:20 GMT.
• Date → Timestamp uses your browser's date and time picker. It reads the date as your local time and gives the timestamp in seconds. The picker has no seconds, so every result is a whole minute. On a device set to UTC, 14 Nov 2023 22:13 gives 1699999980, not 1700000000.

There are no copy buttons. Select a result with your mouse and copy it. The tool has no ISO 8601 output (such as 2023-11-14T22:13:20Z) and no time zone menu.

Seconds, Milliseconds and the Unit Menu

Unix time is usually counted in seconds. Many systems use smaller units instead. JavaScript's Date.now() and Java's System.currentTimeMillis() both return milliseconds. If a millisecond value is read as seconds, the date lands 1,000 times too far in the future: 1700000000000 would become a date in the year 55840.

To avoid that, the Unit menu starts on Auto-detect. It counts the digits before the decimal point and picks the unit from this table. Under the result, the tool tells you which unit it used, for example Read as milliseconds (13 digits).

The guess is right for dates between 1973 and 5138. Outside that range it can be wrong. For example, 86400000 milliseconds (2 January 1970) has only 8 digits, so Auto-detect reads it as seconds. If the note under the result shows the wrong unit, pick the right one in the Unit menu. The date updates at once.

A few more details about the input box:

• Decimals work. 1700000000.5 in seconds is 14 Nov 2023 22:13:20.500 UTC, and the result shows the milliseconds.
• A browser date has millisecond detail. Any smaller part, such as the last 3 digits of a microsecond value, is dropped. The tool says so under the result when it happens.
• Only digits, one minus sign at the start and one decimal point are accepted. Short forms like 1e9, spaces and commas are not read. The tool shows a message instead of a wrong date. Type 1e9 as 1000000000.
• The largest date a browser can show is 13 September in the year 275760. That is 8,640,000,000,000 seconds after 1970. A larger number shows a message, not a date.
• If you clear the box, the result disappears.

Local Time and UTC

A Unix timestamp has no time zone. The same number is the same moment everywhere. Only the way it is written changes. Here is 1700000000 as the tool shows it on devices in three time zones, with a US English browser:

The local part also follows your browser's language. A British English browser puts the day first and uses a 24-hour clock: 14/11/2023, 22:13:20. The UTC part is always in the same English format.

In the Date → Timestamp section, the time zone changes the result. The same picked time, 14 Nov 2023 22:13, gives 1699999980 on a device set to UTC, 1700017980 in New York and 1699979280 in Kathmandu. To get the timestamp for a time written in UTC, pick that time and then correct the result by your offset. In New York in winter, subtract 18000. In Nepal, add 20700.

Daylight saving time can also surprise you here. In New York, 8 March 2026 has no 02:30, because clocks jump from 02:00 to 03:00. If you pick 02:30 on that day, the browser treats it as 03:30. On 1 November 2026, 01:30 happens twice. The browser uses the first one, which is still daylight saving time.

Dates Before 1970

Negative numbers count back from 1970. -1 is 31 Dec 1969 23:59:59 UTC. -86400 is one full day before the start: 31 Dec 1969 00:00:00 UTC. Picking a date before 1970 in the Date → Timestamp section gives a negative result.

Not every system accepts negative timestamps. For example, the MySQL TIMESTAMP column type only stores dates from 1970 to 2038. For older dates, use a DATETIME column or a 64-bit number.

The Year 2038 Problem

Many older systems store a timestamp as a signed 32-bit integer. The largest value it can hold is 2147483647, which is Tue, 19 Jan 2038 03:14:07 UTC. One second later, the number overflows. It wraps around to -2147483648, and the system reads the date as Fri, 13 Dec 1901 20:45:52 UTC. Enter both numbers in the tool to see these two dates.

This tool is not affected. Browsers store dates as 64-bit numbers, so 2147483648 shows correctly as 19 Jan 2038 03:14:08 UTC. The risk is in other places: old 32-bit devices and programs, database columns declared as a 32-bit INT, and file formats that save the time in 4 bytes. Systems that use a 64-bit time value do not have this problem.

Leap Seconds

Unix time ignores leap seconds. Every day counts as exactly 86,400 seconds, so "one day later" is always +86400. This tool follows the same rule. The cost is small: the difference between two timestamps does not include any leap seconds in between. Twenty-seven leap seconds have been added since 1972.

Getting a Timestamp in Code

Each line below returns the current time in whole seconds:

JavaScript   Math.floor(Date.now() / 1000)
Python       int(time.time())
PHP          time()
Java         Instant.now().getEpochSecond()
Go           time.Now().Unix()
MySQL        SELECT UNIX_TIMESTAMP();
PostgreSQL   SELECT extract(epoch FROM now())::bigint;
Shell        date +%s

To turn a timestamp back into a date in a terminal, use date -d @1700000000 on Linux, or date -r 1700000000 on macOS.