Unix Timestamps Explained: Epoch Time to Date and Back

You open a log file, an API response or a database row and find 1700000000 where a date should be. It is not corrupt. It is a Unix timestamp, perhaps the most widespread way software records "when".

This guide explains what the number means, why systems use it, the traps that cause wrong dates (seconds versus milliseconds, time zones, overflow), and how to convert in either direction with a free tool.

What a Unix timestamp is

A Unix timestamp counts the seconds since 00:00:00 UTC on 1 January 1970, the Unix epoch. Zero means that exact moment. One day later is 86400, because a day has 86,400 seconds. Dates before 1970 are negative numbers.

A few reference points you can verify:

• 0 is 1 January 1970, 00:00:00 UTC.
• 1000000000 is 9 September 2001, 01:46:40 UTC.
• 1700000000 is 14 November 2023, 22:13:20 UTC.
• 2147483647 is 19 January 2038, 03:14:07 UTC.

Unix time also ignores leap seconds, treating every day as exactly 86,400 seconds. For almost every purpose that is a feature: arithmetic stays simple.

Why programs use timestamps

A date such as "03/10/2026" is ambiguous (is it March or October?), depends on a calendar, and needs a time zone before it identifies a moment. A timestamp is one integer that means the same thing everywhere. That gives you:

• Easy sorting. Larger number means later.
• Easy arithmetic. Add 3600 for an hour later, 86400 for a day.
• Compact storage. An integer beats a formatted string.
• No locale confusion. Formatting is left to the display layer.

How to convert a timestamp to a date

1. Open the Timestamp Converter.
2. Paste the epoch value into Unix epoch (seconds).
3. Read the date shown below it. It uses your browser's local time zone and prints something like a full day, date, time and zone name.
4. If the result says "Invalid timestamp", the field contains something that is not a number.

The converter loads with the current time already filled in, and Use current time resets it to now.

How to convert a date to a timestamp

1. In the same tool, choose a date and time in the Date & time box. It is interpreted in your local time zone.
2. Click Convert to epoch.
3. The seconds value appears in the epoch field above.

If you need the epoch for a particular time in UTC, make sure your device's zone is what you expect, or work out the offset yourself. A date entered as "09:00" in New York and "09:00" in Berlin are different timestamps.

Seconds versus milliseconds

This is the most common source of nonsense results. Unix systems and many databases use seconds (10 digits at present). JavaScript's Date.now(), Java and many JSON APIs use milliseconds (13 digits).

This converter expects seconds. If you paste 1700000000000 (milliseconds), it will interpret it as a number of seconds and show a date tens of thousands of years in the future, around the year 55,000. The fix is to drop the last three digits, or divide by 1000.

A quick rule: if the date looks absurdly far ahead, you probably have milliseconds.

Time zones and daylight saving

A timestamp has no time zone. It points at one instant. Zones appear only when you format it. The same value displays as 22:13 in London in winter, 17:13 in New York and 07:13 the next morning in Tokyo.

Common ways to go wrong:

• Storing local times without a zone, then reading them elsewhere.
• Assuming a day is always 24 hours when daylight saving shifts a day to 23 or 25.
• Comparing a timestamp displayed in local time with one displayed in UTC.

A good habit: store and transmit timestamps or UTC, and convert to local time only when showing it to a person. For counting down to a date, Countdown to Date does the arithmetic for you.

The Year 2038 problem

If a system stores the timestamp in a signed 32-bit integer, the largest value is 2,147,483,647: 03:14:07 UTC on 19 January 2038. One second later it wraps to a large negative number, which software interprets as a date in 1901. Modern 64-bit systems can represent dates billions of years away, so most current software is safe. The risk is in old embedded devices, legacy databases and file formats with 32-bit fields.

Where current tools fall short

Plenty of epoch converters exist, but common frustrations include: pages that guess seconds or milliseconds for you and sometimes guess wrong, results shown only in UTC or only in local time, pages cluttered with ads, and tools that send your value to a server for no reason. This one runs in the tab and uses your device clock and zone.

The caveats: it works in seconds only, shows a single local-time string rather than a list of formats, and accepts only the date and time you can enter in the browser's picker. It does not format ISO 8601 or custom patterns. For those, use your language's date library.

Everyday use cases

• Reading logs. Convert the number in a log line to see when the event happened.
• Debugging an API. Check that an expiry or created_at field is in the future or the past you expect. Paste the JSON into the JSON Formatter first if it is hard to read.
• Setting expiry values. Work out the timestamp for a certain date and time.
• Scheduling. Find the epoch for an event, then add 3600 times the hours you need.
• Discord-style timestamps. Discord's message timestamp syntax takes a seconds value, so this tool can supply the number.

Reading timestamps in practice

A few patterns come up repeatedly once you start reading raw epoch values.

Differences are durations. Subtract two timestamps and you get seconds between them. 1700003600 minus 1700000000 is 3600, exactly one hour. Divide by 86400 for days. This makes timeouts and expiry checks trivial: a token issued at time T with a lifetime of 900 seconds expires at T plus 900.

Round numbers are suspicious. If you see 0 or a negative number where a date should be, the field was probably never set and the default epoch is leaking through. A date in January 1970 in a user interface is a classic sign of a missing value.

Precision varies. Some systems store seconds, some milliseconds, and a few microseconds or nanoseconds, which have 16 and 19 digits. Count the digits first, then divide down to seconds before pasting into the converter.

Local conversion is for people. When you convert with the Timestamp Converter, the displayed date is in your own zone. If you are debugging a server in another region, convert in your head to UTC, or compare two values from the same system rather than relying on the clock time shown.

A last tip for scheduling: pick the target date and time in the converter, click Convert to epoch, then add or subtract multiples of 3600 to move by hours.

Tips and mistakes to avoid

• Count digits before you convert. Ten means seconds, thirteen means milliseconds.
• Always note the zone. If you share a converted date, say which zone it is in.
• Use UTC for storage. Local time for display only.
• Do not treat timestamps as dates for age maths. For years of age, use the Age Calculator.
• Watch for the 2038 limit when working with 32-bit systems.
• Remember the date picker's local interpretation when generating epochs for servers in other zones.

Related reading

If you work with data formats, see CSV vs JSON: when to use each and how minified JSON helps debugging. For unique identifiers, read UUID v4 explained. More utilities live in developer tools.