Convert a Unix epoch timestamp in seconds, milliseconds, microseconds or nanoseconds to a date in UTC or a major world time zone, and a date back to a timestamp.
Nothing you enter is stored - it is converted and returned in the same request.
Logs, databases and APIs store time as a Unix timestamp: the seconds since 1 January 1970 UTC. Paste one to see the real date and time in your time zone, or turn a date into the timestamp a query or API call needs.
A timestamp for a date in the present day has 10 digits in seconds (1767225600 is 1 January 2026, 00:00 UTC), 13 in milliseconds, 16 in microseconds and 19 in nanoseconds. The tool reads the size: values below 10^11 are taken as seconds, below 10^14 as milliseconds, below 10^17 as microseconds, and anything larger as nanoseconds. JavaScript's Date.now() and most Java APIs give milliseconds; Unix tools, Python's time.time() and most databases give seconds. You can override the guess.
A Unix timestamp is always UTC; the zone only matters when you show it to a person. Going the other way, a local time can be ambiguous: when clocks go back, 01:30 happens twice, and when they go forward, 02:30 never happens at all. The tool warns in both cases instead of picking one silently, which is the usual source of a report that is an hour off twice a year.
A negative timestamp is a date before 1970: -86400 is 31/12/1969 00:00 UTC. The tool accepts any moment from -62135596800 (01/01/0001 00:00:00 UTC) to 253402300799 (31/12/9999 23:59:59 UTC). Decimals are kept as fractions of a second, so 1700000000.5 is 22:13:20.5 UTC on 14/11/2023. Detection only looks at size, so a millisecond value from before 03/03/1973 has 11 digits or fewer and is read as seconds: 86400000 shows 27/09/1972 instead of 02/01/1970. Set the unit to Milliseconds for old values like that.
In Excel or Google Sheets, =A1/86400+DATE(1970,1,1) turns seconds in cell A1 into a UTC date (divide by 86400000 for milliseconds); format the cell as date and time. For local time add the UTC offset in hours divided by 24, for example +9/24 for Tokyo. =(A1-DATE(1970,1,1))*86400 goes back from a date to seconds. In PostgreSQL, to_timestamp(1700000000) returns a timestamptz and EXTRACT(EPOCH FROM column) goes back; in MySQL, FROM_UNIXTIME(1700000000) and UNIX_TIMESTAMP(column) both use the session time zone. Paste the same value here to check a formula: 1700000000 must come out as 14/11/2023 22:13:20 UTC.
The value was probably in seconds but read as milliseconds, or it was 0 or empty in the source system. A date in January 1970 almost always means a missing value, not a real event.
No. Unix time ignores leap seconds, so every day is exactly 86,400 seconds. This matches how computers, databases and APIs store time.
Count the digits. Today a timestamp in seconds has 10 digits and one in milliseconds has 13. The converter detects this for you, and you can set the unit yourself.
No. It counts seconds from a single moment in UTC, so the same timestamp is the same instant everywhere. Only the way it is displayed depends on the time zone.
Systems that store the timestamp as a signed 32-bit number overflow on 19/01/2038. This converter uses full-size numbers and handles dates up to the year 9999.
In JavaScript, Math.floor(Date.now() / 1000) gives seconds; Date.now() on its own gives milliseconds. In Python, int(time.time()). In a Linux or macOS shell, date +%s. In PostgreSQL, EXTRACT(EPOCH FROM now()) (with decimals), and in MySQL, UNIX_TIMESTAMP(). The live clock on this page shows the same value in seconds, ready to copy.
40 common zones from the IANA time zone database, each named after a city, from UTC and Asia/Kolkata (India) to America/Los_Angeles and Pacific/Auckland. Each zone applies its own daylight-saving rules for the date you convert. Your browser's zone is preselected when it is on the list; otherwise the page starts on UTC. If your city is missing, pick a listed city on the same clock today, for example Europe/Berlin for Vienna.
Use both cards. Choose Asia/Kolkata as the time zone, enter 14/11/2023 and 10:00 under Date to timestamp and press Convert: you get 1699936200. Paste that into Timestamp to date, then switch the time zone to America/New_York. Timestamp to date now shows 13/11/2023 23:30:00 at UTC offset -05:00, the evening before in New York. Daylight saving is applied for the date you enter, so 10:00 in India on 14/07/2023 is 00:30 on 14/07/2023 in New York, at -04:00. Changing the zone also re-reads the date typed under Date to timestamp as New York time, so take the answer from Timestamp to date.
Attributes such as lastLogonTimestamp and pwdLastSet are Windows FILETIME values: 100-nanosecond intervals since 01/01/1601 UTC, not Unix time. Pasted as is, 133446720000000000 is read as nanoseconds and shows 25/03/1974. Divide by 10000000 and subtract 11644473600 first: the result, 1700198400, is 17/11/2023 05:20:00 UTC. In Excel, =A1/864000000000-109205 gives the same UTC date and time; in PowerShell, [DateTime]::FromFileTimeUtc(133446720000000000).
Enter its parts under Date to timestamp: 14/11/2023 as the date and 22:13:20 as the time. Choose a time zone with the same offset on that date, Asia/Kolkata for +05:30 or UTC for a value ending in Z, and press Convert: the answer is 1699980200. If no listed zone has the offset, subtract it yourself and enter the time in UTC: 22:13:20+05:30 is 16:43:20 UTC. Timestamp to date shows ISO 8601 in UTC and in local time, ready to copy.