How to Read Unix Timestamps in Logs, Fast

Why logs use raw numbers at all

Logging frameworks, databases, and CDNs could print "2026-08-07 00:00:00 UTC" — and many do. But a raw integer has three advantages that keep it in production output: it is unambiguous across timezones, it sorts and compares with plain operators, and it costs almost nothing to emit. Machines love it; only the human reading the log pays the price.

The 30-second routine

When a number like 1786060800 shows up in a log line, work through this in order:

Count the digits. Today (and until late 2286), seconds are 10 digits, milliseconds are 13, and microseconds are 16. If it has 19 digits, you are probably looking at nanoseconds. If you are not sure, the unit-detection guide has the full digit tables.
Check for landmarks. Is the value anywhere near 1700000000 (November 2023), 1600000000 (September 2020), or 1500000000 (July 2017)? Round billions are easy to spot and date the log within a couple of years.
Convert once, deliberately. Paste the value into the timestamp-to-date converter and read the UTC row first. UTC is the ground truth; convert to your local zone only if the log's convention calls for it.

The contexts where you will meet them

File timestamps. stat, ls --full-time, and find -printf all expose raw seconds — stat prints them as Birth and Modify fields. On GNU systems date -d @1786060800 decodes one immediately; on BSD and macOS the flag is date -r 1786060800.
Application logs. Java's System.currentTimeMillis() writes 13-digit values; Python loggers configured with %(created)f or time.time() write fractional seconds; PHP and Go services usually write whole seconds. A single service can mix all three, which is exactly how unit confusion starts.
Databases. UNIX_TIMESTAMP() in MySQL and EXTRACT(EPOCH FROM ...) in Postgres return seconds, but schema migrations and ORMs frequently store milliseconds because the application layer produced them.
APIs and tokens. JWT claims (iat, exp, nbf) are always seconds. Analytics events and telemetry payloads are usually milliseconds.
Error pages and stack traces. When a crash report includes a raw value "for reference", it is normally the moment the process started or the event fired — decode it before you go looking for an external timestamp.

Decoding without a website

Sometimes a number appears mid-debugging and opening a browser breaks your flow. A few terminal one-liners cover the common cases (adjust for your platform's date):

GNU/Linux: date -d @1786060800 -u → 2026-08-07 00:00:00 UTC.
BSD/macOS: date -r 1786060800 -u.
Python: python3 -c "import datetime;print(datetime.datetime.fromtimestamp(1786060800, datetime.timezone.utc))".
JavaScript (in a browser or Node REPL): new Date(1786060800 * 1000).toISOString().

The multiplications are where unit bugs sneak in, so when precision matters use a tool that auto-detects the unit instead of typing the scale factor yourself.

Reading a whole file of timestamps

If a log or export contains hundreds of raw values, do not convert them one by one. The batch converter on the home page turns a pasted list into a table in one pass and exports the result as TSV or CSV — which is also the fastest way to sanity-check a whole column of millisecond values against a column of seconds.

Make the habit stick

After a few weeks of decoding logs, the landmarks become automatic: 1_700_000_000-ish values are 2023–2026, values in the 1_76x_xxx_xxx range are 2026, and 13-digit values starting 17… are milliseconds from the same era. When you do reach for a converter, remember the golden rule of log forensics: always read the UTC row first. If the local-time row disagrees with what the system owner expected, the timezone is the second thing to suspect — after the unit.