Unix Timestamp Converter Explained With Examples

A Unix timestamp is a compact way for computers to store a moment in time. Instead of writing "26 May 2026 at 14:30 in London", a system can store one number that counts how many seconds have passed since a fixed starting point.

That starting point is the Unix epoch: 00:00:00 UTC on 1 January 1970. A timestamp of 0 means exactly that moment. A positive timestamp means a time after it. A negative timestamp means a time before it.

Unix timestamps are everywhere in programming. You see them in APIs, databases, server logs, analytics exports, payment systems, scheduled jobs, and error reports. They are efficient, sortable, and language-neutral. They are also easy to misread if you mix up seconds, milliseconds, UTC, and local time.

What a Unix Timestamp Is

A Unix timestamp represents a point in time as a number. In the classic form, the number is a count of seconds since the Unix epoch.

For example:

• 0 = 1970-01-01 00:00:00 UTC
• 60 = 1970-01-01 00:01:00 UTC
• 3600 = 1970-01-01 01:00:00 UTC
• 86400 = 1970-01-02 00:00:00 UTC

Because each day has 86,400 seconds in ordinary Unix time, adding 86,400 moves the timestamp forward by one day.

The timestamp does not store a time zone name. It stores a moment. Time zone conversion happens when that moment is displayed to a person.

That is the key idea. A timestamp is the instant. A readable date is a presentation of that instant.

The Unix Epoch

The Unix epoch is:

1970-01-01 00:00:00 UTC

UTC means Coordinated Universal Time. It is the global reference time used in computing, aviation, science, and many international systems.

Why 1970? Unix was developed around that period, and the date became the conventional zero point for Unix time. The choice is historical rather than magical. What matters is that systems agree on the same starting point.

Unix timestamps before 1970 are negative. For example, a date in 1960 has a negative timestamp because it happened before the epoch. Not every system handles negative timestamps equally well, especially older software, but the concept is valid.

Seconds vs Milliseconds

The most common timestamp mistake is confusing seconds with milliseconds.

A seconds-based Unix timestamp is usually 10 digits for current dates:

1716726600

A milliseconds-based timestamp is usually 13 digits:

1716726600000

The millisecond version is the seconds version multiplied by 1,000.

This difference matters because many languages and tools use different conventions:

If you paste a 13-digit timestamp into a converter expecting seconds, you may get a date thousands of years in the future. If you paste a 10-digit timestamp into code expecting milliseconds, you may get a date in January 1970.

UTC vs Local Time

Unix timestamps are based on UTC. They do not include your local time zone.

Suppose a timestamp represents:

2026-05-26 12:00:00 UTC

Displayed in London during British Summer Time, that same moment is:

2026-05-26 13:00:00 Europe/London

Displayed in New York during Eastern Daylight Time, it is:

2026-05-26 08:00:00 America/New_York

The timestamp has not changed. Only the display has changed.

This is why two people in different countries can convert the same timestamp and see different local clock times. Both can be correct if the converter is showing local time.

A good timestamp tool should make clear whether it is showing UTC, local time, or both.

Step-by-Step Example: Reading a Timestamp

Take this timestamp:

1716726600

Step 1: Count the digits.

It has 10 digits, so it is probably seconds.

Step 2: Convert from Unix seconds to UTC.

The UTC result is:

2024-05-26 12:30:00 UTC

Step 3: Convert to local time if needed.

In London on 26 May 2024, daylight saving time is active, so local time is:

2024-05-26 13:30:00 BST

In Los Angeles on the same date, local time is:

2024-05-26 05:30:00 PDT

Step 4: Decide which display is needed.

For an API payload, UTC or ISO 8601 may be best. For a user-facing dashboard, local time may be clearer.

Step-by-Step Example: Seconds vs Milliseconds

Now compare these two numbers:

1716726600

1716726600000

The second number is exactly 1,000 times larger. It represents the same moment if interpreted as milliseconds.

If a program expects seconds:

1716726600 is correct.

If a program expects milliseconds:

1716726600000 is correct.

If you send 1716726600000 to a seconds-based system, it may try to read it as a date around the year 56,363. If you send 1716726600 to a milliseconds-based system, it may read it as January 1970.

The quick check is:

• 10 digits usually means seconds.
• 13 digits usually means milliseconds.
• 16 digits may mean microseconds.
• 19 digits may mean nanoseconds.

"Usually" is doing work here. Some old timestamps, far future timestamps, and decimal timestamps break the simple digit rule. But it catches most everyday mistakes.

Where Unix Timestamps Appear

APIs

APIs often return timestamps because they are compact and unambiguous. A response might include:

{
  "created_at": 1716726600,
  "expires_at": 1716813000
}

The API documentation should say whether those values are seconds or milliseconds. If it does not, count digits and test a known record.

Databases

Databases may store time as Unix integers, timestamp columns, datetime strings, or ISO 8601 text. Unix integers are easy to sort and index, but they are not very readable without conversion.

Logs

Server logs and application logs often include timestamps to track events precisely. A log entry may use Unix time because it is easy for machines to compare.

Analytics

Analytics tools record events such as page views, sign-ups, purchases, and errors. Timestamps allow the system to group events by minute, hour, day, or user journey.

Programming

Developers use timestamps for caching, expiry checks, scheduling, rate limiting, session handling, and measuring durations.

For example, a token might expire when:

current timestamp > issued timestamp + 3600

That means "expire one hour after issue".

ISO 8601 and Human-Readable Dates

ISO 8601 is a standard format for writing dates and times. It commonly looks like this:

2026-05-26T12:30:00Z

The T separates the date and time. The Z means UTC. You may also see an offset:

2026-05-26T13:30:00+01:00

That means the local clock time is 13:30, and the time zone offset is one hour ahead of UTC.

ISO 8601 is often easier for humans to read than a Unix timestamp, while still being structured enough for software. Many APIs now prefer ISO 8601 strings for clarity. Unix timestamps remain common where compact numeric values are convenient.

Converting a Date Back to a Timestamp

Conversion works in both directions. If you start with a readable date, first decide what time zone the date belongs to.

Suppose you want a timestamp for:

2026-05-26 09:00 in London

On that date London is using British Summer Time, which is UTC+1. The UTC time is therefore:

2026-05-26 08:00:00 UTC

That UTC moment can then be converted to a Unix timestamp. If the system expects seconds, store the seconds value. If it expects milliseconds, multiply by 1,000 or use a tool that outputs milliseconds directly.

This is where many scheduling bugs begin. A developer may type 09:00 as if it were UTC when the user meant 09:00 local time. The stored event then appears one hour early or late. The fix is to capture the intended time zone before conversion.

Common Mistakes

Mistake 1: Treating local time as UTC

If someone says "the timestamp should be 9 AM", ask 9 AM where. A timestamp must represent a precise moment, so the time zone matters during conversion.

Mistake 2: Mixing seconds and milliseconds

This is the classic bug. JavaScript uses milliseconds for Date.now(), while many APIs use seconds. Always check the expected unit.

Mistake 3: Removing three zeros blindly

Dividing by 1,000 can fix milliseconds to seconds, but only if the original value is actually milliseconds. Do not remove zeros without checking.

Mistake 4: Ignoring daylight saving time

Local time conversion depends on the date. London is UTC+0 in winter and UTC+1 in summer. New York is usually UTC-5 in winter and UTC-4 in summer. Use a real time zone, not a fixed offset, when accuracy matters.

Mistake 5: Assuming every day has exactly 24 civil hours

Unix time counts seconds consistently, but local civil days can be 23 or 25 hours when daylight saving time changes. This matters for calendars, billing periods, and reports.

Mistake 6: Storing only formatted local dates

A local date string like 05/06/2026 09:00 can be ambiguous. Is that 5 June or 6 May? Which time zone? Numeric timestamps or ISO 8601 strings avoid much of that ambiguity.

Use the BlinkCalc Timestamp Converter

The Timestamp Converter helps you convert Unix timestamps into readable dates and convert readable dates back into timestamp values.

It is especially useful when you need to:

• Check an API response.
• Debug a log entry.
• Convert a database value.
• Compare UTC and local time.
• Confirm whether a value is seconds or milliseconds.

When using any converter, check the unit first. If the number has 13 digits and the result looks wrong, try milliseconds. If it has 10 digits and the result lands in 1970, the tool or code may be expecting milliseconds.

If you are comparing elapsed time rather than converting a date, the Time Calculator can help with time differences.

Practical Use Cases

Debugging an expired session

A developer sees expires_at: 1716813000 in an API response. Converting it shows the exact UTC expiry time, which can then be compared with the user's local time and the current server time.

Reading an analytics export

A CSV export includes event timestamps as 13-digit numbers. The analyst recognises them as milliseconds, converts them, and groups events by local business day.

Investigating a production error

A server log records an error at Unix time 1716726600. Converting it to UTC lets the team compare it with deployment logs, database queries, and monitoring alerts.

Scheduling cache expiry

A program stores the current timestamp plus 600 seconds. That creates an expiry time 10 minutes in the future.

FAQ

What is a Unix timestamp?

A Unix timestamp is a number representing a moment in time, usually counted in seconds since 1970-01-01 00:00:00 UTC.

What is the Unix epoch?

The Unix epoch is the starting point for Unix time: midnight UTC on 1 January 1970.

Is a Unix timestamp in seconds or milliseconds?

Classic Unix timestamps are in seconds, but many systems use milliseconds. Current seconds timestamps are usually 10 digits, while milliseconds are usually 13 digits.

Are Unix timestamps always UTC?

Unix timestamps are based on UTC. They do not store a local time zone. Local time is applied only when displaying the timestamp.

Why does JavaScript use 13-digit timestamps?

JavaScript Date.now() returns milliseconds since the Unix epoch, which makes current values 13 digits long.

What is ISO 8601?

ISO 8601 is a standard date and time format, such as 2026-05-26T12:30:00Z. It is readable and unambiguous when the time zone or offset is included.

Can Unix timestamps be negative?

Yes. Negative timestamps represent moments before 1970-01-01 00:00:00 UTC, although some older systems may not handle them well.

Why does the same timestamp show a different time on my computer?

Your converter may be displaying local time. The timestamp represents the same moment, but local clock time depends on your time zone and daylight saving rules.

Conclusion

Unix timestamps are simple once you separate the instant from the display. The number counts time from the Unix epoch in UTC. The readable date depends on whether you interpret the value as seconds, milliseconds, UTC, or local time.

When a timestamp looks wrong, check the digit length, the expected unit, and the time zone. Those three checks solve most timestamp confusion.