Unix Timestamp
Epoch seconds and milliseconds to ISO dates
A Unix timestamp counts seconds since midnight UTC on 1 January 1970. It has no time zone, no daylight saving and no calendar — just an integer — which is exactly why it is the format systems use to record when something happened. Every conversion into a human-readable date is an interpretation applied afterwards.
The two things that catch people out are units and time zones. JavaScript works in milliseconds while most other languages and databases work in seconds, so a value off by a factor of a thousand lands you in 1970 or in the year 55,000. And a timestamp rendered without stating its zone is ambiguous by up to a day. This tool shows both UTC and your local time.
How to use it
- Paste a timestampSeconds and milliseconds are both accepted, and the length of the value tells them apart — ten digits is seconds, thirteen is milliseconds.
- Read UTC and local side by sideSeeing both at once is the quickest way to catch an off-by-one-day error caused by a zone offset near midnight.
- Convert a date backEnter a date and get the timestamp, which is what you need when constructing a query against a table storing epoch integers.
Frequently asked questions
Is a timestamp in seconds or milliseconds?
Count the digits. A current timestamp in seconds has ten; in milliseconds it has thirteen. Unix tooling, most databases and most languages use seconds, while JavaScript’s Date.now and Java’s currentTimeMillis use milliseconds. Mixing them is one of the most common date bugs there is.
What is the year 2038 problem?
A signed 32-bit integer overflows on 19 January 2038, wrapping to a negative number and to 1901. Any system still storing time in a 32-bit signed field will get it wrong on that date. Modern platforms use 64-bit values, which push the limit far beyond any practical horizon, but embedded and legacy systems remain exposed.
Do Unix timestamps account for leap seconds?
No, and deliberately so. Unix time defines every day as exactly 86,400 seconds, so a leap second is not represented — the clock either repeats or skips a value depending on the platform. This keeps the arithmetic simple at the cost of not being a true count of elapsed SI seconds since the epoch.
Can a timestamp be negative?
Yes. Negative values represent times before 1970, which is how dates of birth or historical records are stored in epoch form. Some libraries and databases reject them, so it is worth testing rather than assuming.
Should I store dates as timestamps or as ISO strings?
Integers are compact, sort naturally and are unambiguous, which suits event times and log entries. ISO 8601 strings are readable, carry an offset and can express a date with no time at all. For something like a birthday — a calendar date rather than an instant — a timestamp is actively the wrong choice, because it forces a zone onto a value that does not have one.