Unix Timestamp Converter

How to Use This Unix Timestamp Converter

1. To read a timestamp, paste it into the first panel. The converter updates as you type and shows the same moment four ways: as a UTC string, in your own local time, in ISO 8601 format, and in relative words such as how long ago it was.
2. Leave the unit on Auto unless you know better. Auto treats a value with twelve or more digits as milliseconds and anything shorter as seconds, which covers almost every real timestamp. If a result lands in 1970 or in a distant century, your value was probably the other unit, so switch the unit manually and compare.
3. Watch the live clock when you need a value for right now. The line above the first panel refreshes every second with the current timestamp and its UTC reading, ready to copy into a test, a query or a fixture.
4. To create a timestamp, use the second panel. Pick a date and time, choose whether that wall-clock time should be read as UTC or as your local time, and press the button. You get both the seconds value most APIs expect and the milliseconds value JavaScript uses.
5. Use the note line as your error check. Plain-language messages there tell you when an entry is not a whole number or falls outside the range a browser can represent, instead of leaving you with a silently wrong date.

What a Unix Timestamp Actually Is

A unix timestamp, also called epoch time or POSIX time, is a single number: the count of seconds that have passed since the start of 1 January 1970 in UTC. That starting moment is the epoch. Every later moment is just a bigger number, and a moment before the epoch is a negative number, which is why old timestamps in a database sometimes show as small negative values rather than as errors.

The idea survives because it removes every ambiguity that makes dates painful in software. A timestamp has no time zone, no daylight saving rule, no month lengths and no language-specific month names. Two systems on opposite sides of the world agree on what 1700000000 means, and they only disagree if they choose to display it differently. Sorting timestamps sorts time itself, and subtracting two of them gives an exact duration in seconds, which is why logs, databases, cookies, tokens and API responses are full of these numbers even though humans cannot read them at a glance. This page exists for that glance: the decoding step between the number a system stores and the moment a person means.

Seconds, Milliseconds and the Auto Rule

The most common conversion bug in real projects is not a time zone. It is a unit mismatch. Unix time was defined in seconds, and most databases, server APIs and shell tools still speak seconds, which today means a ten-digit number. JavaScript, however, counts milliseconds natively, so browser and Node timestamps are thirteen digits. Java works in milliseconds too, and some high-precision systems go further, to microseconds or nanoseconds.

Unit	Digits today	Example for the same moment	Common in
Seconds	10	1700000000	APIs, databases, shell, PHP, Python
Milliseconds	13	1700000000000	JavaScript, Java, browser events
Microseconds	16	1700000000000000	High-precision logs and tracing

The Auto setting on this converter uses digit count as its clue: twelve or more digits means the value must be milliseconds, because a seconds value that large would describe a year tens of thousands of years in the future, while a milliseconds value that short would describe a moment in January 1970. The twelve-digit boundary rather than thirteen also catches the milliseconds values for dates in late 2001, when the milliseconds count itself had twelve digits. If you are ever unsure which unit a system gave you, convert both ways deliberately with the unit selector: the sensible date is the right one, and the absurd one will be obvious at a glance.

Worked Examples

Example 1: the round number. The timestamp 1700000000 converts to Tuesday, 14 November 2023 at 22:13:20 UTC. Developers used it as a test value for months before it arrived precisely because it is easy to type and easy to recognize in a log. In the second panel, entering 2023-11-14 and 22:13:20 with the mode set to UTC returns exactly 1700000000 seconds and 1700000000000 milliseconds, a neat round trip to check the tool against.

Example 2: the epoch itself. Timestamp 0 is Thursday, 1 January 1970 at 00:00:00 GMT, the zero point of the whole system. If a converted date shows the start of 1970, the value you were handed was almost certainly empty, missing or measured in the wrong unit, which makes the epoch the most useful diagnostic in this whole topic.

Example 3: milliseconds detected. Paste 1700000000000 with Auto selected and you get the same November 2023 date as example one, not a date in the year 55872. The thirteen digits give the unit away, the converter divides by a thousand behind the scenes, and the UTC, local and ISO lines agree with the seconds version to the second.

Example 4: local against UTC. A date entered as 2023-11-14 at 22:13:20 in local mode produces a different epoch from the same numbers in UTC mode unless your device itself is set to UTC. Neither answer is wrong. They describe two different moments that share a wall-clock reading, which is exactly the class of bug the mode selector exists to expose before it ships.

Time Zones, Relative Time and the 2038 Question

A timestamp itself never carries a time zone. The zone appears only when a person reads it, which is why this converter always shows UTC and your local reading side by side. Most mysterious off-by-some-hours bugs are born at that display step: a correct timestamp rendered in the wrong zone, then copied back into a system as if the rendered text were the truth. Working in UTC end to end, and converting to local only for display, prevents nearly all of them.

The relative line answers a different question: not when exactly, but how it sits against now. It picks the largest sensible unit, so a recent log line reads as minutes ago, an old database row as months or years ago, and a scheduled future event as in so many days. That is the form support teams and on-call engineers actually think in at three in the morning.

One limit deserves a mention. Very old software stored timestamps in a signed 32-bit integer, which runs out in January 2038, the famous Year 2038 problem. Modern browsers and 64-bit systems describe a far wider range, but if a value from an embedded device or a legacy database converts strangely near that boundary, the storage width, not the conversion, is the usual culprit.

Common Mistakes to Avoid

• Feeding milliseconds into a seconds field. The date lands tens of thousands of years in the future, or the library quietly overflows. Count the digits first: ten means seconds, thirteen means milliseconds.
• Assuming a displayed local time is UTC. Copying a local rendering back as if it were UTC shifts the moment by your full zone offset. Keep the original number whenever you can, and convert the number, not the text.
• Rounding away milliseconds in tests. A fixture built from whole seconds will never reproduce a bug that depends on event ordering within the same second. Keep the milliseconds value the second panel gives you when precision matters.
• Storing timestamps as formatted strings. Strings sort badly, compare badly and hide their zone. Store the number, format it only when a human needs to read it, exactly as this page does.
• Forgetting negative timestamps exist. Dates before 1970 are valid and negative. A converter or a spreadsheet that rejects them will silently misplace historical dates, birth dates in old records and test data set before the epoch.

More Developer Tools on This Site

Timestamps sit in a family of time and number formats worth handling together. The Discord Timestamp Converter turns the same epoch values into Discord markdown tags that render as live local times for every reader, the Time Calculator adds and subtracts durations, and the Date Calculator counts days between two dates. For the number systems underneath the code, the Binary Converter shows values in base 2 and the Military Time Converter handles 24-hour clock readings.

Frequently Asked Questions

What is the current unix timestamp?

It changes every second, so this page shows it live at the top of the tool, together with its UTC reading. As a rough guide, the seconds value passed 1700000000 in November 2023 and grows by 86,400 every day.

How do I convert from a unix timestamp to a date?

Paste the number into the first panel. The converter works out whether it is seconds or milliseconds, then shows the moment in UTC, in your local time, in ISO 8601 format and in relative words. The timestamp 1700000000, for example, is 14 November 2023 at 22:13:20 UTC.

How do I tell seconds from milliseconds?

Count the digits. A current timestamp in seconds has ten digits, while the same moment in milliseconds has thirteen. This converter automates that check in Auto mode: twelve or more digits is treated as milliseconds, and anything shorter as seconds.

Why does my timestamp show a date in 1970?

Almost always because a seconds value was read as milliseconds, a milliseconds value was divided one time too many, or the real value was empty and defaulted to zero. Timestamp 0 is the epoch itself, 1 January 1970, so a result near that date is a unit or missing-data clue, not a real event time.

How do I convert a date back to a timestamp?

Use the second panel. Pick the date and time, decide whether that reading is UTC or your local time, and press the button. Choosing UTC reads the numbers exactly as written on a UTC clock; choosing local applies your device time zone. The result is given in both seconds and milliseconds.

Is a unix timestamp affected by time zones or daylight saving?

No. The number counts seconds from a single UTC moment and never changes with zones or seasons. Time zones only affect how the number is displayed to a person, which is why the same timestamp shows two different clock readings, UTC and local, in the results above.