What it does
- The unit is guessed from the number of integer digits: up to 11 digits seconds, 12–14 milliseconds, 15–17 microseconds, more is nanoseconds. Twelve digits overlap (“seconds in the year 9999” and “milliseconds in 1973–2001”), so pick the unit when it matters.
- A date without an offset such as
Zor+09:00is read as wall-clock time in the selected zone. A time skipped by a daylight-saving change is read with the offset before the change, and a repeated time as the first one (the same as Pythonzoneinfowithfold=0). - Everything is calculated in your browser, in whole numbers down to the microsecond.
Examples
| Input | Result |
|---|---|
0 | 1970-01-01T00:00:00Z |
1760842800 | 2025-10-19T03:00:00Z (12:00 in Asia/Seoul) |
2147483647 | 2038-01-19T03:14:07Z — the end of signed 32-bit |
-1.5 | 1969-12-31T23:59:58.500000Z |
2026-10-19 12:00:00 (Asia/Seoul) | 1792378800 |
How the check was made
Before release the results were compared with Python datetime and zoneinfo for 24 cases (14 timestamp → date, 10 date → timestamp), including negative and fractional seconds, the 2038 boundary and both New York daylight-saving changes.
FAQ
How do I convert on the command line?
With GNU date: date -d @1760842800 turns a timestamp into a date and date -d '2026-10-19 12:00:00' +%s turns a date into seconds. Prefix TZ=Asia/Seoul to pick the time zone.
What is the year-2038 problem?
Storing seconds in a signed 32-bit integer overflows after 2147483647 (2038-01-19 03:14:07 UTC). Current Linux with a 64-bit time_t is not affected, but old devices, file formats and database columns still are.
Is anything I type sent to a server?
No. The conversion happens entirely in your browser. The input is not sent to a server and is not passed to the visitor statistics or the ads this site uses. Details are on the privacy page.