A Unix timestamp, also called Unix time or epoch time, is the number of seconds that have passed since 00:00:00 UTC on 1 January 1970, the "Unix epoch". It is a plain integer, which is why databases, APIs and log files like it: it sorts correctly, subtracts cleanly, and takes eight bytes at most. The value 1790726400, for example, is 00:00:00 UTC on 30 September 2026. That is 9:00 AM in Seoul and 5:00 PM on 29 September in Vancouver, but the number is the same everywhere.
Two details follow from the definition. Dates before 1970 are negative: -86400 is 31 December 1969, because a day is 86,400 seconds. And leap seconds are not counted; Unix time assumes every day has exactly 86,400 seconds, so converting a timestamp never produces 23:59:60.
The most common mistake with timestamps is mixing up the unit. Classic Unix time is in seconds and has 10 digits for any date between 2001 and 2286. JavaScript's Date.now(), Java's System.currentTimeMillis() and many JSON APIs use milliseconds, which gives 13 digits: 1790726400000 is the same midnight as above. Some systems go further, with 16 digits for microseconds and 19 for nanoseconds.
Paste a 13-digit value into a converter set to seconds and you get a date around the year 58,000; paste a 10-digit value as milliseconds and you land in early 1970. Count the digits before you do anything else. The Unix timestamp converter does not guess: its Seconds and Milliseconds buttons decide how your number is read, and the ISO 8601 line makes a wrong guess obvious immediately.
A timestamp is an instant, not a clock reading. Two people in Seoul and Vancouver looking at 1790726400 are looking at the same moment; only the local clock time they would write for it differs. So there is no such thing as a "Seoul timestamp" or a "UTC timestamp" as opposed to a local one. The zone only enters the picture when a human-readable date is produced, or when one is parsed.
That second case is where bugs hide. A date without a time zone, such as 2026-09-30 or 2026-09-30 09:00, is ambiguous: parsed as Seoul time it becomes one timestamp, parsed as Vancouver time another, 16 hours apart. The fix is to carry the zone with the string, as ISO 8601 does with 2026-09-30T00:00:00Z or 2026-09-30T09:00:00+09:00, and to store the timestamp rather than the local string.
JavaScript works in milliseconds, so divide or multiply by 1,000:
Math.floor(Date.now() / 1000)new Date(1790726400 * 1000).toISOString() gives "2026-09-30T00:00:00.000Z"Math.floor(Date.parse("2026-09-30T00:00:00Z") / 1000) gives 1790726400Python works in seconds as a float. Always pass a time zone, because a naive datetime is interpreted in the machine's local zone (the examples assume from datetime import datetime, timezone):
import time; int(time.time())datetime.fromtimestamp(1790726400, tz=timezone.utc) gives 2026-09-30 00:00:00+00:00int(datetime(2026, 9, 30, tzinfo=timezone.utc).timestamp()) gives 1790726400SQL varies by database, and the display functions use the session's time zone, so check it when the result looks an hour or more off:
SELECT UNIX_TIMESTAMP(); and SELECT FROM_UNIXTIME(1790726400);SELECT EXTRACT(EPOCH FROM now())::bigint; and SELECT to_timestamp(1790726400);SELECT strftime('%s', 'now'); and SELECT datetime(1790726400, 'unixepoch'); gives 2026-09-30 00:00:00Excel and Google Sheets store dates as a count of days, so a timestamp in cell A1 becomes a date with =A1/86400 + DATE(1970,1,1), formatted as a date and time. The result is UTC; add or subtract hours yourself for local time. The reverse is =(A1 - DATE(1970,1,1)) * 86400. For milliseconds, divide by 86,400,000 instead.
Many older systems store Unix time as a signed 32-bit integer, whose largest value is 2,147,483,647. That is 03:14:07 UTC on 19 January 2038. One second later the value wraps around to −2,147,483,648, which reads as 13 December 1901, and anything doing date arithmetic on it breaks. Modern 64-bit operating systems and languages, JavaScript included, are unaffected, but embedded devices, old file formats and the TIMESTAMP column type in older MySQL versions still carry the limit. If you store timestamps, use a 64-bit integer; if you maintain anything built before about 2010, it is worth checking.
The Unix timestamp converter shows the current timestamp live, ticking once a second. Paste any value, choose Seconds or Milliseconds, and read it as ISO 8601, a UTC string, a local string in your browser's time zone, both units of the timestamp, and a relative time such as "3 days ago". The Date to Timestamp panel goes the other way; the date and time you type are read in your browser's time zone, so 09:00 on a laptop set to Seoul becomes 00:00 UTC. Typing in either panel pauses the live clock so the result holds still for copying; each line has its own copy button.
The relative time is a rough check, floored to the largest unit, with months counted as 30 days. For an exact number of days between two dates use the date calculator. For turning a timestamp's UTC reading into another city's clock, the time zone converter handles daylight saving for the date in question. Timestamps most often arrive inside API responses, and the JSON formatting guide covers the related question of whether to send them as numbers or strings.
Open the free Unix timestamp converter — the current epoch time, live, plus conversion in both directions.
It changes every second, so read it live on the Unix timestamp converter. For scale, 00:00:00 UTC on 30 September 2026 was 1790726400, and the value grows by 86,400 each day.
Neither, strictly: it is a count of seconds since 1 January 1970 UTC and is the same number everywhere. Time zones only matter when you turn it into a readable date, or parse a local date into one. A date string without a zone is ambiguous; a timestamp never is.
Count the digits. Ten digits is seconds for any date between 2001 and 2286; thirteen digits is milliseconds. JavaScript and Java produce milliseconds, Python, PHP and most databases produce seconds.
Systems that store Unix time in a signed 32-bit integer reach their maximum, 2,147,483,647, at 03:14:07 UTC on 19 January 2038 and wrap around to 1901. 64-bit systems are unaffected; the problem lives in embedded devices and old software.