Timestamp → date
Convert several values (paste log lines)
{ } Timestamps usually live inside JSON — read the answer now.
Epoch, ISO 8601, local time and Windows FILETIME, both ways — with time zone offsets and batch mode for log lines.
{ } Timestamps usually live inside JSON — read the answer now.
Logs, APIs, databases and monitoring systems hand out time as seconds since 1970 — perfect for machines, unreadable for humans. This tool converts in both directions and always shows the timezone offset, because that is where almost every mistake happens.
A Unix timestamp (also epoch time) counts the seconds since 1 January 1970, 00:00:00 UTC — no time zones, no leap seconds. Because the count is defined in UTC, a timestamp always describes one exact point on the global timeline; only when displaying it does it shift into a zone such as Europe/Berlin. That is why logs all over the world carry the same number while your team reads different wall-clock times.
Resolution is the most common source of error. date +%s and Python's time.time() give seconds (10 digits), JavaScript's Date.now() and Java give milliseconds (13 digits), journalctl and Wireshark sometimes write microseconds (16 digits) and some kernel logs nanoseconds (19), while Windows uses FILETIME (18 digits). This converter detects the unit from the digit count and tells you what it detected — and the selector next to it lets you override that. A misread value lands in 1970 or in the year 33658; you see both in the result and in the warning line.
A timestamp itself is never ambiguous — its display is. Europe/Berlin sits at +02:00 (CEST) in summer and +01:00 (CET) in winter; on the autumn switch day the hour between 02:00 and 03:00 happens twice, and in spring it does not exist at all. Any interval calculation across that day produces exactly one error per year. That is why this converter shows the zone with its current offset, prints the ISO 8601 representation including the offset (2026-09-12T22:31:00+02:00) and warns you when your input carried no zone and was therefore read as local time.
FILETIME is the timestamp of the Windows world: a 64-bit value counting 100-nanosecond intervals since 1 January 1601 UTC. You run into it where you least expect it — in registry values such as LastConnected or LastSeen, in AD and WMI exports, in event log data and in Get-Item output. Eighteen digits are typical, and the number itself tells you nothing. This converter detects 18-digit numbers as FILETIME automatically (and uses BigInt internally, because an 18-digit value exceeds what a JavaScript number can represent exactly). In PowerShell it works both ways: [datetime]::FromFileTime(134337186600000000) gives you the date, (Get-Date).ToFileTime() gives you the current value. Note that FILETIME is always UTC and carries no time zone — and unlike Unix timestamps it counts from 1601, not from 1970.
On 19 January 2038, 03:14:07 UTC a signed 32-bit counter of seconds reaches its maximum value (2147483647) and overflows. Systems that still store timestamps that way — old 32-bit installations, some embedded devices, databases with INT columns — jump back to 1901. 64-bit systems are unaffected. Type 2147483647 above if you want to see that moment live.
journalctl: with -o short-iso systemd writes ISO time with an offset, in the default format without a zone. Paste either one here and you immediately see when the service really started — locally and in UTC.
Wireshark & tcpdump: capture files carry seconds with fractions since the epoch. Batch mode converts whole lists at once instead of doing the arithmetic line by line.
HTTP headers: Date, Last-Modified, Expires and cookies use the HTTP date format from RFC 7231 (always GMT). That is exactly the line this tool emits, ready to paste into a header test.
JWT and sessions: the iat and exp claims are in seconds. When a token supposedly expired early, the server clock is usually the culprit — compare both values here.
Databases and exports: FROM_UNIXTIME() exists in MySQL but not in Postgres, and MongoDB and CSV exports often contain raw numbers. Here you get every representation side by side, including the ISO week for weekly reports.
Paste the whole line into the batch field below the converter — the parser extracts the timestamp out of the surrounding text itself.
Pick your time zone (the browser remembers it) and compare the ISO 8601 (UTC) column with the column for your zone.
Note the zone and format of the source: a log line without Z or an offset is ambiguous — next time, check how the source writes its time before anything else.
The Z stands for “Zulu”, i.e. UTC. That is the global point in time, not your local clock: in Europe/Berlin it is 22:31 in summer.
By length: 10 digits are seconds (9 digits before 2001), 13 digits are milliseconds. If the value is shorter than you expected, or lands decades in the past or future, the unit is swapped — the selector next to the input fixes that.
No. Europe/Berlin is a region with two offsets (+01:00 and +02:00) depending on daylight saving. An offset like +02:00 is only valid for one moment. Always use the region name when you describe a point in time.
Yes, in the batch field below the converter. One value per line, raw log lines are fine — up to 500 lines are returned as a table with a UTC and a zoned column.
Standards: RFC 3339 (the ISO 8601 profile for the internet) and the IANA time zone database. On systemd timers and log formats: systemd.time(7). On our blog: journald and structured logs, network analysis with Wireshark & tcpdump and JSON in everyday admin life.
🕐 Timestamps understood? If the source was JSON, format it now — our formatter turns compressed API responses and log JSON into readable code in one click.