A Unix timestamp looks like nothing at all: a ten-digit number, such as 1700000000, sitting in a log file, a database column, or an API response. It carries no labels, no dashes, no colons, and no hint of which date it represents. Yet it is one of the most common ways computers store time, because it is compact, unambiguous in one important sense, and easy to compare and sort. The trouble is that the same simplicity that makes timestamps useful also makes them easy to misread. A timestamp in seconds mistaken for milliseconds lands in the year 55,000. A timestamp read in the wrong timezone lands on the wrong day. A timestamp stored as text and sorted alphabetically orders itself incorrectly. Each of these errors is silent, and each produces a date that looks plausible enough to be believed.

A Unix timestamp counts seconds elapsed since 00:00:00 UTC on 1 January 1970, an origin known as the Unix epoch. The count ignores leap seconds in the usual implementations, which is a technical simplification worth knowing but rarely the source of practical errors. What matters in practice is three things: the unit, the timezone, and the range. The Unix Timestamp Converter translates between timestamps and human-readable dates, handling the unit and timezone questions explicitly, so you can convert in either direction without doing epoch arithmetic by hand.

How the tool works

Conversion from a timestamp to a date is division and remainder arithmetic against the epoch, adjusted for the timezone you choose. The converter takes the number, interprets it in the unit you specify, seconds or milliseconds, and renders the corresponding date and time. Conversion in the other direction takes a date and time, interprets it in a stated timezone, and counts the seconds between the epoch and that moment. Both directions depend on the timezone being stated, because the same timestamp corresponds to different clock times in different zones, and the same clock time in different zones corresponds to different timestamps.

The unit question is the first trap. Classic Unix timestamps are in seconds, giving ten digits for dates around the present day. Many modern systems, especially JavaScript-based ones and some APIs, use milliseconds, giving thirteen digits. A thirteen-digit value read as seconds points tens of thousands of years into the future, and a ten-digit value read as milliseconds points to a date in January 1970. Counting digits is therefore a useful first check: ten digits means seconds, thirteen means milliseconds, and anything else deserves a second look. The converter asks for the unit explicitly rather than guessing, because a guess that is wrong produces a confident, wrong date, which is worse than an error message.

The timezone question is the second trap. A timestamp itself has no timezone; it is an absolute moment, the same everywhere. But the human-readable rendering of that moment depends on where you are. Midnight UTC is early morning in Karachi, the previous evening in New York, and mid-morning in Sydney, all for the same timestamp. A converter must therefore state which timezone its output uses, and you must check that it matches the timezone your data was recorded in. A log timestamp rendered in the wrong zone does not just look wrong; it can place an event on the wrong day, which matters for anything dated, from incident reports to financial records. For the neighbouring problem of normalising timestamps across log formats, the Log Timestamp Normalizer handles varied textual formats, and the Time Converter covers conversions between clock representations.

A worked example

Take the timestamp 1700000000, interpreted as seconds. Converting it gives 2023-11-14 22:13:20 UTC. The arithmetic can be checked in outline: 1,700,000,000 seconds divided by 86,400 seconds per day is about 19,675.9 days after the epoch, and 19,675 days after 1 January 1970 lands in mid-November 2023, with the fractional day giving the time of 22:13:20. Rendered in Pakistan Standard Time, which is UTC plus five hours, the same moment reads 2023-11-15 03:13:20, which is the next calendar day. That one example contains the whole lesson: the same timestamp, two correct renderings, different dates, and anyone who records only the date without the timezone has recorded something ambiguous.

Now consider the same digits misread as milliseconds. The value 1700000000 milliseconds is only 1,700,000 seconds, which is about 19.7 days after the epoch, giving a date in late January 1970. A developer who feeds a seconds timestamp into a milliseconds-expecting function, or vice versa, gets a date that is wrong by decades, yet the function returns it without complaint. The defence is a sanity check on every conversion: does the resulting date fall in the era you expect? A user-registration date in 1970 or in the year 55,000 is a unit error, not a data mystery, and catching it takes one glance at the output.

A third worked detail concerns negative timestamps and the year 2038 problem. Dates before the epoch have negative timestamps, which some systems handle and some do not, so pre-1970 dates deserve testing in any system that stores them. Dates after 19 January 2038 overflow a signed 32-bit seconds counter, the well-known 2038 problem, and systems still using 32-bit timestamps will fail on those dates. Modern systems generally use 64-bit counters, but any integration with older equipment or file formats should be checked for this limit before it becomes urgent.

Common mistakes

The most common mistake is mixing seconds and milliseconds. Count the digits, state the unit, and sanity-check the resulting date against the era you expect, every time, not just when something looks wrong.

A second mistake is converting without stating a timezone. A date without a timezone is ambiguous by up to a day, and a timestamp rendered in the viewer's local zone is not necessarily the zone the data was recorded in. Always record the timezone alongside the converted date, or convert to UTC and state that explicitly.

A third mistake is sorting timestamps stored as text. Text sorting orders "9" after "10" alphabetically, which scrambles chronological order once values have different digit lengths. Store timestamps as numbers, or pad them to a fixed width, before sorting.

A fourth mistake is assuming a timestamp encodes the local time it was recorded in. It does not; it encodes an absolute moment. The local clock reading is a rendering of that moment in a particular zone, and reconstructing the original local reading requires knowing which zone was in effect at that moment, including daylight saving rules.

Honest limitations

A timestamp converter translates between a count and a calendar rendering; it cannot tell you which unit or timezone your source data used, and a wrong assumption at input produces a wrong date at output with no warning. It cannot resolve ambiguous local times, such as the hour that occurs twice when clocks go back, without additional information about which occurrence was meant. It also cannot fix timestamps that were recorded incorrectly at the source, whether by a misconfigured clock or a unit error upstream, and it does not account for leap seconds in the way some specialised time systems do. The converter is exact arithmetic on stated assumptions; the assumptions remain yours to verify.

Closing

Timestamps reward three habits: count the digits, state the timezone, and sanity-check the result against the era you expect. With those habits, a ten-digit number becomes a reliable date instead of a guessing game. The Unix Timestamp Converter does the arithmetic, the Log Timestamp Normalizer handles messy log formats, and the Time Converter covers other clock conversions. For the related problem of inconsistent date formats inside tabular data, The Date-Format Detective: One Column, Three Styles, Silent Errors shows how mixed formats cause silent errors. A timestamp converted with its unit and timezone stated is a timestamp you can defend, and one converted without them is a date waiting to be wrong.