Unix Timestamps Explained: Seconds, Milliseconds, and Common Pitfalls

The single integer that represents time across nearly every system

By Wada Tsumi · Published July 8, 2026

What a Unix Timestamp Actually Is

A Unix timestamp (also called Unix time or epoch time) is the number of seconds that have elapsed since midnight UTC on January 1, 1970 — the "Unix epoch." Instead of storing a date as a year, month, day, hour, minute, and second, it's stored as a single integer that counts upward continuously. As of mid-2026, that number is in the neighborhood of 1.78 billion.

This design exists because comparing two timestamps, calculating the duration between them, or sorting a list of events chronologically is just simple arithmetic on integers — no calendar logic, no time zone handling, no leap year edge cases. Nearly every programming language, database, and API represents time internally this way, even if it displays a human-readable date on the surface.

Seconds vs Milliseconds

The single most common Unix timestamp mistake is a units mismatch. Unix time is traditionally defined in seconds, but JavaScript's Date.now() and many JavaScript-based APIs return milliseconds instead — a value 1,000 times larger. Feeding a millisecond timestamp into a function expecting seconds produces a date thousands of years in the future; feeding a second-based timestamp into something expecting milliseconds produces a date stuck near January 1, 1970. If a converted date looks wildly wrong, checking whether the input is in seconds or milliseconds is almost always the fix.

A quick sanity check: current timestamps in seconds are 10 digits long (around 1,780,000,000); the same moment in milliseconds is 13 digits long (around 1,780,000,000,000).

Why UTC, Not Local Time

A Unix timestamp itself has no time zone — it's an absolute count of seconds since the epoch, identical everywhere in the world at any given instant. Time zone only enters the picture when you convert that number into a human-readable date, since "what time is it" depends on where you are. This is precisely why storing timestamps (rather than pre-formatted local date strings) in databases and APIs is the standard practice: the same stored number can be correctly displayed as 3:00 PM in New York and 8:00 PM in London without any ambiguity about which moment is meant.

Common Conversion Pitfalls

Off-by-one-day errors near midnight — converting a timestamp to a date without accounting for the viewer's time zone can shift the displayed date by a day if the actual moment falls near midnight in that zone
Daylight saving time — a timestamp converted to local time in a zone that observes DST needs to know which offset applied at that specific historical moment, not just the zone's current offset
The Year 2038 problem — systems that store Unix time as a signed 32-bit integer will overflow on January 19, 2038; most modern systems have already moved to 64-bit representations, but older embedded or legacy systems can still be affected
Assuming a timestamp is always UTC — while the Unix timestamp value itself is timezone-agnostic, some legacy systems store "local" timestamps that don't actually represent true UTC seconds, causing conversion errors when treated as standard Unix time

Where You'll Run Into Timestamps

API responses — created_at, updated_at, and expires_at fields are frequently returned as raw Unix timestamps rather than formatted dates
JWT claims — the iat (issued-at) and exp (expiration) fields in a JSON Web Token are Unix timestamps in seconds
Log files — many logging systems timestamp each entry as epoch time for compact, sortable storage
Database columns — some schemas store timestamps as integers rather than native datetime types, particularly in systems optimized for high write throughput
Cache expiration — cache and session systems often use a Unix timestamp to mark when an entry should expire

Converting Timestamps in Code

Every mainstream language provides a built-in way to convert between Unix time and a structured date:

JavaScript — new Date(timestamp * 1000) for seconds-based input, since the Date constructor expects milliseconds
Python — datetime.fromtimestamp(timestamp) from the datetime module
SQL — most databases provide a function like TO_TIMESTAMP() or FROM_UNIXTIME() depending on the dialect

Quick FAQ

Why does my timestamp show a date in the year 55,000 or similar? This is almost always a seconds-vs-milliseconds mismatch — the value was likely in milliseconds but treated as seconds, multiplying the resulting date far into the future.

Do Unix timestamps account for leap seconds? No — Unix time simplifies by ignoring leap seconds entirely, treating every day as exactly 86,400 seconds, which occasionally causes it to drift very slightly from true astronomical time.

Is a negative Unix timestamp valid? Yes — negative values represent moments before the epoch (before January 1, 1970), and are supported by most conversion tools and libraries for historical date calculations.

Convert Timestamps Instantly

Use the DataBench Unix Timestamp Converter to convert between Unix time and human-readable dates in either direction, with support for both seconds and milliseconds — right in your browser.