Unix Timestamp Seconds vs Milliseconds: How to Tell the Difference

The easiest way to tell Unix timestamp seconds from milliseconds is usually their scale. A current Unix timestamp in seconds is typically about 10 digits long, while the same instant in milliseconds is typically about 13 digits long. Milliseconds are simply the seconds value multiplied by 1,000.

For example:

Both values can represent the same instant. The second number is just expressed using a smaller unit.

This distinction matters because different programming languages, APIs, databases, and browser functions do not necessarily use the same unit. JavaScript's Date.now(), for example, returns milliseconds since January 1, 1970 UTC, while Python's time.time() returns seconds since the epoch as a floating-point value. (MDN Web Docs)

If you have an unknown epoch value, you can test it with the CurrentDateTime Unix Timestamp Converter.

Seconds vs Milliseconds at a Glance

The core relationship is:

1 second = 1,000 milliseconds

So:

seconds × 1000 = milliseconds

and:

milliseconds ÷ 1000 = seconds

What Is a Unix Timestamp in Seconds?

Traditional Unix time represents time using the number of seconds elapsed since the Unix epoch.

The Unix epoch is: January 1, 1970 at 00:00:00 UTC.

POSIX defines its seconds-since-the-Epoch representation around this seconds-based model and treats each represented day as exactly 86,400 seconds. (The Open Group)

So a value such as: 1700000000 means roughly 1.7 billion seconds have elapsed since the epoch. The number itself does not include a formatted year, month, day, or timezone name. Software converts it into a human-readable date when needed.

What Is a Unix Timestamp in Milliseconds?

A millisecond timestamp uses the same basic epoch but counts thousandths of a second instead.

JavaScript is a major example. MDN documents that: Date.now() returns the number of milliseconds elapsed since January 1, 1970 at 00:00:00 UTC. (MDN Web Docs)

Likewise, JavaScript's Date.prototype.getTime() returns milliseconds since the same epoch. (MDN Web Docs)

So if Unix seconds are: 1700000000, the millisecond equivalent is: 1700000000000. The instant has not changed. Only the unit has.

Why Are Seconds Usually 10 Digits?

Modern dates are far enough from 1970 that a seconds-based Unix timestamp is currently around 1.7 to 1.8 billion.

That produces values around: 1xxxxxxxxx or roughly 10 decimal digits. This is why developers often use: 10 digits = probably seconds as a quick diagnostic rule.

But "probably" is important. Digit count is a useful heuristic, not a formal definition.

Why Are Milliseconds Usually 13 Digits?

Milliseconds multiply the seconds value by 1,000. Multiplying by 1,000 adds three decimal places to an integer timestamp.

So: 1700000000 becomes: 1700000000000. That is why current millisecond timestamps are typically around 13 digits.

A 13-digit epoch-looking number from a modern application is therefore often milliseconds.

The Quickest Way to Tell Them Apart

For modern dates, this rule works well as an initial check:

• 10 digits: likely Unix seconds
• 13 digits: likely Unix milliseconds

For example: 1750000000 looks like seconds; 1750000000000 looks like milliseconds.

You can confirm by converting the value. If interpreting the 13-digit value as seconds gives an absurd far-future or out-of-range date, but dividing it by 1,000 produces a sensible date, you have probably found a millisecond timestamp.

Why Digit Count Is Not a Perfect Test

Digit count works well for contemporary dates, but it can fail outside the normal modern range.

• A very early timestamp may contain fewer digits.
• A far-future seconds timestamp could eventually become longer.
• Negative timestamps add a minus sign.
• Microsecond and nanosecond timestamps are even larger.
• A system may also use an entirely different epoch.

So production software should not determine timestamp units only from length unless the data contract explicitly permits that approach. The best source of truth is always: API documentation, database schema, language documentation, or: the field definition.

A Better Test: Convert Both Interpretations

If documentation is unavailable, try interpreting the number both ways.

Suppose you receive: 1700000000000.

Treat it as seconds

That means 1.7 trillion seconds after 1970. The result is nowhere near an ordinary contemporary date.

Treat it as milliseconds

Divide by 1,000: 1700000000. Now the value represents a plausible modern date.

That strongly suggests the original unit was milliseconds. You can do this quickly with the CurrentDateTime Unix Timestamp Converter.

Seconds to Milliseconds Conversion

To convert Unix seconds to milliseconds: multiply by 1,000.

For example: 1700000000 × 1000 = 1700000000000.

So: 1700000000 seconds = 1700000000000 milliseconds. Both represent the same point in time.

Milliseconds to Seconds Conversion

To convert milliseconds to seconds: divide by 1,000.

For example: 1700000000000 ÷ 1000 = 1700000000.

If the millisecond timestamp contains sub-second information, division may produce a fractional seconds value. For example: 1700000000123 ÷ 1000 = 1700000000.123. That .123 represents 123 milliseconds beyond the whole second.

Do Not Always Throw Away the Remainder

Suppose you have: 1700000000123. If you convert to whole seconds by integer division, you get: 1700000000. The remaining: 123 milliseconds is lost.

That may not matter if your application only needs second-level precision. It could matter for: logs, financial events, performance telemetry, message ordering, analytics, distributed systems.

Decide whether losing sub-second precision is acceptable before rounding or truncating.

JavaScript Uses Milliseconds

One of the most common sources of confusion is JavaScript. MDN states that Date.now() returns milliseconds elapsed since the Unix epoch. (MDN Web Docs)

For example: const now = Date.now(); returns a millisecond value. Likewise: new Date().getTime(); returns milliseconds. (MDN Web Docs)

So if an API gives you Unix seconds and you pass the number directly into a JavaScript Date constructor expecting milliseconds, your result can be wrong.

The Classic JavaScript Seconds Bug

Imagine an API returns: 1700000000 in seconds. A developer writes: new Date(1700000000).

JavaScript interprets that number as milliseconds, not seconds. So instead of treating it as roughly 1.7 billion seconds after 1970, it treats it as only 1.7 billion milliseconds after 1970.

That places the displayed date near the beginning of the Unix era (January 1970) rather than the intended modern date.

The fix is: new Date(1700000000 * 1000) when you have confirmed that the source value is seconds.

Why Dates Near 1970 Often Mean a Unit Bug

If you expect a recent date but your software displays something around January 1970, check your timestamp units.

A common situation is: seconds value passed to a milliseconds API. The seconds number is roughly one-thousandth of the expected millisecond number. When interpreted as milliseconds, it represents only a relatively short time after January 1, 1970.

So an unexpected 1970 date is a useful debugging clue. It is not absolute proof, but it should make you check: seconds vs milliseconds immediately.

Why You Might Get a Far-Future Date

The opposite mistake also happens. Suppose your source gives: 1700000000000 milliseconds, but your application interprets that as seconds.

Now the numeric value is 1,000 times larger than the intended seconds timestamp. That can produce:

• a date thousands of years into the future
• an overflow
• an invalid-date error
• a database range error

Again, check the expected unit before blaming timezone conversion.

Python Commonly Uses Seconds

Python's standard time module takes the opposite convention from JavaScript's ordinary Date API.

Python documentation describes time.time() as returning time in seconds since the epoch, typically as a floating-point number. (Python documentation)

That means a value might look like: 1700000000.123456. The whole part represents seconds. The decimal part represents fractional seconds. This difference between Python and JavaScript is a common source of integration bugs.

JavaScript vs Python Timestamp Example

Suppose both systems represent the same instant.

Python might produce something conceptually like: 1700000000.123.
JavaScript might represent it as: 1700000000123.

The first is seconds with a fraction. The second is integer milliseconds. They can represent the same moment. But you cannot compare them numerically until their units match.

Always Normalize Before Comparing

Suppose: System A gives seconds: 1700000000; System B gives milliseconds: 1700000000500.

If you compare the raw integers: 1700000000500 > 1700000000, the second value looks vastly later.

But after normalizing:

• System A: 1700000000000 ms
• System B: 1700000000500 ms

the actual difference is: 500 milliseconds. Always compare timestamps in the same unit.

Never Compare Seconds Directly With Milliseconds

This sounds obvious, but it causes real bugs.

Suppose: Created time: 1700000100 seconds; Updated time: 1699999999000 milliseconds.

A raw numeric comparison is meaningless. Convert both to seconds or milliseconds first. Then compare.

How to Detect Seconds or Milliseconds Programmatically

If you control the data format, do not detect it. Define it.

For example: created_at_seconds or: created_at_ms is much safer than: timestamp.

Documentation could say: created_at is Unix time in milliseconds. That eliminates guessing.

If you do not control the input, you can use a reasonableness test based on an expected date range.

For example:

1. Interpret as seconds.
2. Convert to a date.
3. Check whether the date falls inside the application's valid range.
4. If not, try milliseconds.
5. Reject ambiguous or impossible values instead of silently guessing.

This is safer than a digit-count rule alone.

Use Magnitude Instead of String Length Carefully

You may also see logic like: if timestamp > 100000000000: treat as milliseconds.

This can work for a controlled modern-date range, but it embeds assumptions about which dates are valid. That may be appropriate for a social-media app that only stores dates after 2010, but not for historical archives or far-future schedules.

Document the supported range if you use magnitude-based detection.

Negative Timestamps Make Length Checks Trickier

Unix-style timestamps can be negative for dates before the epoch on systems that support them. The IETF TZif specification describes negative Unix values as representing pre-epoch times. A leading minus sign therefore complicates simplistic digit-length logic.

For example: -1000000000 is not 11 numeric digits of magnitude. It is a sign plus a 10-digit magnitude. If you must inspect length, normalize the sign first. Better yet, use explicit metadata.

Seconds vs Milliseconds for Current Dates

For contemporary dates, the difference is visually large. Consider:

• Seconds: 1760000000
• Milliseconds: 1760000000000

Both follow the same pattern. Milliseconds add three decimal positions because: 1 second = 1,000 milliseconds. This is why the 10-versus-13-digit shortcut works so well for current systems.

What About Microseconds?

Some systems use microseconds instead. One second contains: 1,000,000 microseconds.

So a modern microsecond epoch value is typically around: 16 digits.

Conceptually:

• Seconds: 1700000000
• Milliseconds: 1700000000000
• Microseconds: 1700000000000000

Again, the same instant can be represented at different precision levels.

What About Nanoseconds?

A nanosecond is one billionth of a second. Modern nanosecond epoch values can be around: 19 digits.

Conceptually: 1700000000000000000. This is common in high-resolution logging, systems programming, and some database or telemetry systems.

Do not assume every long epoch number is milliseconds. Check the scale.

Seconds, Milliseconds, Microseconds and Nanoseconds

EpochConverter, for example, supports seconds, milliseconds, microseconds, and nanoseconds, reflecting how commonly these different units appear in real systems. (Epoch Converter)

Again, digit count is a practical clue rather than a formal type declaration.

Why More Precision Exists

Imagine ten events all happen within one second. A seconds-only timestamp might assign the same integer to all of them. Milliseconds allow up to 1,000 positions inside that second. Microseconds allow one million. Nanoseconds allow one billion theoretical units per second.

Whether the underlying clock can actually measure time at that precision is a separate question. A timestamp can have nanosecond fields without the system clock being accurate to a nanosecond.

Precision Is Not the Same as Accuracy

This is an important technical distinction. A system might store: 1700000000123456789 with nanosecond-looking precision. That does not automatically mean the clock is accurate to one nanosecond.

Precision describes how finely the representation can express values. Accuracy describes how close the clock is to the true reference time. Do not infer clock quality from timestamp length.

Date.now() vs performance.now()

JavaScript provides another useful distinction. Date.now() is based on milliseconds since the Unix epoch. (MDN Web Docs)

performance.now() is different. MDN explains that it is relative to a performance time origin rather than directly being a Unix epoch timestamp. (MDN Web Docs)

So performance.now() should not be treated as an epoch millisecond timestamp. Not every number measuring time is Unix time.

Not Every Numeric Timestamp Uses the Unix Epoch

This is another reason automatic detection can be dangerous. A number might represent:

• Unix seconds
• Unix milliseconds
• Unix microseconds
• Unix nanoseconds
• elapsed time since application start
• another platform-specific epoch
• database-specific time units

Before applying "10 digits means seconds," first establish that the field is actually Unix/epoch-based.

Unix Seconds Do Not Store a Time Zone

Seconds versus milliseconds has nothing to do with timezone. Both: 1700000000 and: 1700000000000 can represent the same global instant.

Neither says: New York, London, India, Tokyo. The timezone appears only when the application converts the instant for display.

So if your displayed hour is wrong by five hours, that may be a timezone problem. If your displayed year is around 1970 or thousands of years away, that is more likely to be a unit problem.

Unit Bug vs Timezone Bug

A useful debugging rule is:

• Wrong by a few hours: Check the timezone.
• Wrong by exactly one hour seasonally: Check daylight saving time.
• Wrong by decades or thousands of years: Check seconds vs milliseconds.
• Wrong by a factor of 1,000: Definitely investigate timestamp units.

This is not an absolute rule, but it is a very useful diagnostic pattern.

Example of a Seconds-to-Milliseconds API Bug

Suppose a server returns: { "created_at": 1700000000 }. The API documentation says: Unix seconds. Your frontend uses JavaScript.

If you do: new Date(created_at), the browser treats the number as milliseconds.

Instead use: new Date(created_at * 1000). Now the units match what JavaScript expects.

Example of a Milliseconds-to-Seconds Backend Bug

Suppose a browser sends: 1700000000000 from Date.now(). Your backend function expects Unix seconds.

If you store the raw value as seconds, the resulting timestamp is far outside the intended date range.

Convert it first: 1700000000000 / 1000 = 1700000000. If integer seconds are required, decide whether to floor, round, or retain the fractional remainder according to the application requirements.

Floor vs Round When Converting Milliseconds

Suppose: 1700000000999 ms. Dividing by 1,000 gives: 1700000000.999 seconds. If you need whole seconds, you have several choices.

• Floor: 1700000000 (This represents the beginning of that second.)
• Round: 1700000001 (This chooses the nearest second.)
• Preserve fraction: 1700000000.999 (This retains the full information.)

For timestamps, flooring is common when converting an instant into completed whole seconds since the epoch, but you should follow the receiving system's documented convention.

Integer Division Can Silently Lose Precision

In some languages: milliseconds / 1000 may perform integer division depending on the types involved. That means: 1700000000123 could become: 1700000000 and lose the final 123 milliseconds.

If those milliseconds matter, convert using a data type that preserves the fractional result or store milliseconds directly.

Database Columns Need Clear Units

A database column called: created_at might contain: SQL datetime values, Unix seconds, or Unix milliseconds. You cannot tell from the name. A numeric column called: timestamp is not much better.

Clear schema design helps: created_at_epoch_seconds or: created_at_ms. Even better, document: unit, epoch, precision, allowed range, null behavior. This prevents future developers from needing heuristics.

API Documentation Should State the Unit

Bad documentation: created_at: event timestamp.
Better: created_at: Unix timestamp in seconds.
Better still: created_at: integer seconds since 1970-01-01T00:00:00Z.
For milliseconds: created_at_ms: integer milliseconds since 1970-01-01T00:00:00Z.

Small documentation improvements prevent large integration bugs.

JSON Does Not Tell You the Unit

A JSON value such as: "created_at": 1700000000000 is simply a number. JSON does not know whether that number means: milliseconds, seconds, money, an ID, or something else.

Meaning comes from the API contract. Never assume the serialization format determines the timestamp unit.

Unix Timestamp Seconds in Python

Python's standard time.time() returns seconds since the epoch as a floating-point number. (Python documentation)

For whole seconds, a developer may intentionally convert that result to an integer. For millisecond precision, a developer might multiply seconds by 1,000, though modern APIs may offer more explicit high-resolution functions depending on the use case. The important part is to keep the unit clear.

Unix Timestamp Milliseconds in JavaScript

JavaScript's standard date representation is strongly associated with milliseconds. MDN documents both Date.now() and Date.prototype.getTime() as returning milliseconds since January 1, 1970 UTC. (MDN Web Docs)

That means JavaScript developers frequently need: Math.floor(Date.now() / 1000) when an API specifically asks for Unix seconds. And they need: seconds * 1000 when converting API seconds into a JavaScript Date.

JavaScript Temporal Makes Units More Explicit

JavaScript's newer Temporal API makes some units clearer through property names. For example, MDN's Temporal.Instant.prototype.epochMilliseconds documentation explicitly identifies the result as an integer number of milliseconds since the Unix epoch. (MDN Web Docs)

Explicit names such as: epochMilliseconds are much safer than a vague field called: timestamp because the unit is visible in the API itself.

How to Validate an Incoming Timestamp

A robust validation workflow is:

1. Confirm the expected epoch.
2. Confirm the documented unit.
3. Parse the value as a numeric type that can safely hold it.
4. Convert it to a readable UTC date.
5. Check whether the resulting date is reasonable for your application.
6. Reject impossible values.
7. Only then convert into the user's local timezone.

This separates three different problems: representation, validity, and display.

Use an Expected Date Range

Suppose your application stores account creation dates and launched in 2022. A timestamp that converts to: 1970 or: year 55,000 is clearly suspicious.

You could enforce an acceptable range such as: 2022 through the current date. That helps detect incorrect units before the value enters your database. The range should match the application's actual domain rather than a generic assumption.

Do Not Silently Guess When Both Interpretations Are Valid

Sometimes a value can theoretically produce a valid date under more than one interpretation. If the data is important, do not silently choose. Return an error such as: "Timestamp unit must be specified as seconds or milliseconds." Explicit failure is often safer than silently storing the wrong instant.

Seconds and Milliseconds Around the Unix Epoch

Near January 1970, digit length becomes particularly unreliable. For example: 1000 could mean: 1,000 seconds after the epoch or: 1,000 milliseconds after the epoch. Both are valid and both are short numbers. Only the unit tells you which is intended. This is one reason length detection is mostly useful for contemporary dates, not as a universal timestamp parser.

Negative Millisecond Values

Dates before January 1, 1970 can also be expressed in milliseconds by using negative values in systems that support them.

Conceptually: -1000 ms is: one second before the Unix epoch, while: -1 second also identifies that one-second-before boundary in a seconds-based representation. Again, unit metadata matters.

Why This Bug Can Survive Testing

Seconds-vs-milliseconds bugs sometimes remain hidden because developers test only one side of an integration. The API unit looks reasonable. The frontend unit looks reasonable. The mistake appears only when the two systems exchange the value.

This is especially common in stacks such as: Python backend + JavaScript frontend because Python commonly exposes epoch seconds while JavaScript's Date APIs expect milliseconds. (MDN Web Docs)

Integration tests should verify the exact same known instant end to end.

Use a Known Timestamp in Tests

A simple way to test timestamp handling is to use a known instant whose value and expected date are fixed. For example, the Unix epoch: 0 must correspond to: January 1, 1970 at 00:00:00 UTC.

Then test a modern known timestamp in both seconds and milliseconds. The second and millisecond representations should resolve to the same instant after proper conversion. This catches unit mismatches quickly.

Unix Time Still Has the Same Epoch in Both Units

There is a common misconception that a "millisecond timestamp" is a different timestamp system. Usually it is not. Both seconds and milliseconds can use: January 1, 1970 at 00:00:00 UTC as their starting point.

What changes is the unit used to count elapsed time:

• Seconds: 1 unit = 1 second
• Milliseconds: 1 unit = 0.001 second

Same epoch. Different scale.

Leap Seconds Do Not Explain the 1,000x Difference

If two timestamps differ by approximately a factor of 1,000, the issue is almost certainly the unit, not leap seconds. POSIX seconds-since-the-Epoch treats represented days as exactly 86,400 seconds. (The Open Group) Leap-second behavior is a separate technical issue and does not turn a 10-digit timestamp into a 13-digit one.

Unix Seconds vs Milliseconds vs ISO Dates

These are three separate representations.

• Unix seconds: 1700000000
• Unix milliseconds: 1700000000000
• Human-readable timestamp: 2023-11-14T22:13:20Z

The first two are numeric epoch representations. The third is a structured date-time string. A system can convert between them while preserving the same underlying instant.

Which Format Should You Use?

There is no universal answer.

Use seconds when:

• your API contract uses Unix/POSIX seconds
• second-level precision is sufficient
• compatibility with seconds-based systems matters

Use milliseconds when:

• your runtime naturally uses milliseconds
• sub-second ordering matters
• your API explicitly defines milliseconds

Use a readable timestamp when:

• humans inspect the values frequently
• timezone offsets need to be explicit
• interoperability benefits from a structured date-time representation

The important rule is consistency.

Can You Store Both?

You generally do not need to store both seconds and milliseconds for the same instant. One can be derived from the other, subject to precision.

If you store milliseconds: 1700000000123, you can derive whole seconds. But if you store only: 1700000000, you cannot recover the original 123 milliseconds because that precision was never stored. Choose the finest precision your application actually needs.

Common Seconds vs Milliseconds Mistakes

The Rule to Remember

For modern Unix timestamps:

about 10 digits = probably seconds

about 13 digits = probably milliseconds

and:

milliseconds = seconds × 1,000

But do not make digit count your only production rule.

The safest process is: check the documentation → confirm the epoch → confirm the unit → convert to a known date → validate the expected range.

This becomes especially important when moving timestamps between languages. JavaScript's standard Date APIs use milliseconds, while Python's common time.time() interface uses seconds. (MDN Web Docs)

If you have an unknown value, paste it into the CurrentDateTime Unix Timestamp Converter and compare the seconds and millisecond interpretations. If you then need to display the resulting instant in another city, use the CurrentDateTime Time Zone Converter.