Unix Timestamp Converter

A count of seconds since midnight UTC on 1 January 1970, which is called the epoch. It carries no timezone: the number is identical everywhere on earth and only its display differs, which is exactly why systems store it rather than a formatted date. The epoch was chosen in the early 1970s as a convenient recent round date, not for any deeper reason.

Count the digits. For any date from 2001 to 2286, seconds have ten digits, milliseconds thirteen, microseconds sixteen and nanoseconds nineteen. Unix tools and most databases use seconds; JavaScript, Java and most JSON APIs use milliseconds; Go's monotonic clock and many tracing systems use nanoseconds. Getting it wrong by a factor of a thousand puts the date in 1970 or in the year 57,000, which is at least obvious once you look.

A signed 32-bit integer runs out at 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. A system storing time that way wraps to negative and lands in December 1901. Most current software moved to 64 bits long ago, but embedded devices, old file formats and some database columns have not, and anything computing a date more than a decade ahead can hit it today rather than in 2038.

No, and that is deliberate. A day is defined as exactly 86,400 seconds, so the count stays arithmetically simple at the cost of drifting from astronomical time by the 27 leap seconds inserted since 1972. When one occurs, systems typically repeat or smear a second rather than counting it. It means the difference between two timestamps is not quite the number of seconds that physically elapsed, which matters for almost nothing outside timekeeping itself.

Because the timestamp has no timezone and the display does. The number is the same instant everywhere; what differs is which zone it is being rendered in, and servers very often run in UTC while the people reading the output do not. The offset also depends on the date rather than on today, since daylight saving means New York is five hours behind London in January and four in July, and the two do not change over on the same weekend.

A date before 1970. It is perfectly valid arithmetic and most systems handle it, but a surprising amount of software does not: date pickers that refuse it, databases that store the count as unsigned, and code that treats a negative as an error. It is worth testing if you deal with birth dates or historical records.