How to convert a timestamp
- Paste a Unix timestamp into the first field. The unit is detected from its length.
- Override the detection with the Seconds or Milliseconds buttons if needed.
- Or pick a date and time to convert in the other direction.
- Read the result in Unix seconds, milliseconds, ISO 8601, local time and UTC.
- Press Copy all to take every representation at once.
What this converter shows
- Automatic detection of seconds, milliseconds and microseconds from the number's length.
- ISO 8601, local time, UTC string and relative time, all at once.
- The day of the week, which is often what you actually wanted to know.
- Your device's detected time zone, so you know what local means.
- Conversion in both directions from the same panel.
- Live updating as you type, with nothing uploaded.
What a Unix timestamp is
A Unix timestamp counts the seconds elapsed since midnight UTC on 1 January 1970. That moment is called the epoch, and it was chosen simply because it was a convenient round date shortly before Unix was written.
Its virtue is that it is a single number with no time zone, no calendar and no formatting. Two systems anywhere in the world comparing timestamps agree instantly, which is why almost every log file, database and API stores time this way and formats it only for display.
Seconds or milliseconds?
This is the commonest source of confusion, because different platforms chose differently. Unix tools, most databases and most APIs use seconds. JavaScript, Java and many newer systems use milliseconds. The same moment is 1700000000 in one and 1700000000000 in the other.
Get it wrong by a factor of a thousand and the date lands in 1970 or in the year 55,000. Both obviously wrong, which is at least a clear signal. The detection here uses the number's length: ten digits is seconds, thirteen is milliseconds, sixteen is microseconds. Override it with the unit buttons when you know better.
Reading the different formats
- ISO 8601: the international standard, always in UTC, ending in Z. Use this in APIs and data interchange.
- Local time: the same moment in your device's time zone, which is what a person wants to read.
- UTC string: the RFC format used in HTTP headers and email.
- Relative: "three hours ago", which is what interfaces usually display.
The problems timestamps do not solve
A timestamp is a moment, not a wall-clock time. If you store a calendar appointment as a timestamp and the user's region changes its daylight saving rules, the appointment moves. Future events with a fixed local time should be stored as a local date plus a time zone identifier, not as an instant.
Leap seconds are also invisible. Unix time pretends every day has exactly 86,400 seconds, so the occasional leap second is simply skipped over. For almost everything that is fine; for scientific timing it is not.
The 2038 problem
Systems storing timestamps as a signed 32-bit integer run out of room on 19 January 2038, when the counter overflows and wraps to 1901. Modern systems use 64-bit integers and are fine for the next 292 billion years, but embedded devices and legacy databases are still working through it.
If you are storing timestamps today, make sure the column is 64-bit. For a more detailed breakdown of epoch time itself, the epoch converter covers the same ground from the other direction, and the date calculator handles arithmetic between two dates. Everything runs in your browser.
Timestamps in log files
Reading logs is where this conversion comes up most. A log line stamped 1700000000 tells you nothing at a glance, and correlating two systems that log in different formats. One in epoch seconds, one in ISO 8601, one in local time with no zone marked, is a familiar and tedious problem.
The advice that saves the most time later is to log in UTC and say so. A log line with a zone-less local timestamp is ambiguous forever, particularly across a daylight saving change where the same hour occurs twice. ISO 8601 in UTC costs a few extra characters per line and removes the ambiguity permanently.