What Unix time counts
A Unix timestamp is the number of seconds since 1970-01-01T00:00:00Z, the POSIX epoch. It is a single integer with no timezone attached — the same instant has the same timestamp in Seoul, London and São Paulo, and only the rendering differs. That is precisely why systems store time this way and format it later.
POSIX defines the count as if every day had exactly 86,400 seconds, so leap seconds are not counted: the timestamp repeats or is smeared across a leap second rather than incrementing through it. For anything short of astronomy or high-frequency trading that simplification is invisible, and it is what keeps the arithmetic trivial.
Landmarks worth recognising on sight: 0 is 1970-01-01T00:00:00Z, 1000000000 is 2001-09-09T01:46:40Z, 1234567890 is 2009-02-13T23:31:30Z, and 1767225600 is 2026-01-01T00:00:00Z. Negative values are legal and address dates before 1970.
Seconds, milliseconds, microseconds, nanoseconds
Languages disagree about the unit, which is where most timestamp bugs begin. JavaScript’s Date.now() and Java’s System.currentTimeMillis() give milliseconds; C, Go’s Unix(), PHP’s time() and most databases give seconds; Python’s time.time() gives fractional seconds; Go’s UnixNano() and many tracing systems give nanoseconds.
For dates in this century the digit count settles it, and that is what auto-detect uses: 10 digits or fewer is seconds, 11–13 is milliseconds, 14–16 microseconds, 17–19 nanoseconds. The detected unit is always shown as a chip you can override, because the rule stops working for dates far outside 1970–2100.
Sub-millisecond digits are kept as text rather than folded into a floating-point number, so a nanosecond trace ID keeps all nineteen digits instead of losing the tail to a double.
ISO 8601, RFC 3339 and RFC 2822
ISO 8601 is the international standard for writing a date and time: 2026-09-06T12:30:00Z, where T separates date from time and Z means UTC. RFC 3339 is a stricter profile of it used across internet protocols — it requires a full date, a time and an offset, so 2026-09-06T21:30:00+09:00 is valid RFC 3339 while 2026-09 is only valid ISO 8601.
RFC 2822 is the email and HTTP header form — Sat, 06 Sep 2026 12:30:00 +0000. Note the numeric offset: JavaScript’s toUTCString() prints "GMT" instead, which is not what the specification asks for, so the card here writes +0000.
When you store a timestamp, store the instant — an integer, or an ISO string with an explicit offset. A local time written without an offset ("2026-09-06 21:30") is ambiguous by construction, and every consumer that reads it has to guess a zone.
Timezones, offsets and DST
An offset such as +09:00 is a number; a timezone such as Asia/Seoul is a rule that says which offset applies on which date. The IANA time zone database — the tzdb your browser ships and updates — holds those rules, and this tool renders any of its roughly 420 zones. Pin several to read one instant in all of them at once.
Converting a date and time into a timestamp is where daylight saving bites, because a local wall clock does not map one-to-one onto instants. In the spring-forward gap the labelled time never happens, and in the autumn fall-back hour it happens twice. The Date → timestamp panel names both cases explicitly and, for the repeated hour, offers the second instant instead of silently picking one.
Korea has no DST, so Asia/Seoul is a flat UTC+9 all year — which is exactly why Korean-built systems tend to discover DST bugs only after their first overseas customer.
Symptoms of getting the unit or zone wrong
- Everything lands on 1 January 1970: a seconds value was read as milliseconds. 1,700,000,000 ms is only 19 days after the epoch.
- Dates land tens of thousands of years in the future: a milliseconds value was read as seconds.
- Everything is off by a whole number of hours: a wall-clock time was converted with the wrong zone, or a UTC instant is being displayed as local without conversion.
- A date-only string is off by one day: in JavaScript, Date.parse("2026-09-06") is interpreted as UTC midnight, while "2026-09-06 00:00" is interpreted as local — a one-line difference that moves the date backwards for anyone west of Greenwich.
Because the tool always shows the instant in UTC, in your local zone and in the zone you chose side by side, a wrong assumption usually announces itself as an offset you did not expect rather than as plausible-looking nonsense.
The 2038 problem and other range limits
A signed 32-bit integer runs out at 2,147,483,647 seconds, which is 2038-01-19T03:14:07Z. Systems still storing time that way wrap to 1901 at that moment — the same class of bug as Y2K, and still present in embedded firmware, old file formats and 32-bit database columns. Anything using 64-bit time, which includes JavaScript, modern Linux and every mainstream database, is unaffected.
This converter is bounded by JavaScript’s own Date range: ±8,640,000,000,000,000 milliseconds from the epoch, about ±273,790 years, roughly the years −271821 to +275760. Values beyond it are reported as out of range rather than silently clamped. Batch mode converts up to 1,000 lines at a time, taking the first 9- to 19-digit number it finds on each line, which is enough to run a log excerpt through it and download the result as CSV.