Reading Timestamps in Log Files and JSON API Responses

Open almost any server log or raw JSON API response and you will eventually hit a field that’s just a number: 1732650000, or maybe 1732650000000. Nothing about the digits themselves says what date that is, or even what unit you’re looking at. This is one of the most common small frictions in debugging — you’re staring at exactly the data you need, and it’s unreadable until you convert it. This guide is a practical walkthrough of how to read those numbers quickly, without guessing.

The digit-count trick

Every Unix timestamp you’ll see in a modern log or API response falls into one of four resolutions, and for any date between roughly 2001 and 2286 they have distinct digit counts:

Each step adds exactly three digits because each unit is 1000× finer than the last, and that ratio holds at any point in the current era — you don’t need to know the actual date to count digits, just count them first and then convert. This is the same detection method our timestamp converter uses automatically, but it’s worth knowing by eye for the moments you’re just skimming a log in a terminal.

Log files: watch for mixed units in the same file

A single log file can genuinely mix resolutions, because it aggregates output from more than one source. A reverse proxy might log request time in seconds while the application server behind it logs in milliseconds; a Node.js process (Date.now() is milliseconds by convention) writing to the same aggregated stream as a Go service (time.Now().Unix()is seconds by convention) will produce exactly this mix. There’s no way to fix this after the fact except converting line by line using each value’s own digit count — assuming file-wide consistency is a reliable way to misread half your log.

If you’re pulling a column of timestamps out of a log for analysis — say, everything matching a greppattern, or a column exported from a log viewer — paste the whole list into a converter that accepts batch input rather than converting values one at a time. Each line gets detected and converted independently, so mixed units in the same paste aren’t a problem.

JSON API responses: string or integer, and how to tell

A JSON payload gives you one more variable: whether the timestamp field is a raw number or a formatted string. Both are common, and neither is inherently better — they’re just different design choices, covered in more depth in our epoch vs. ISO 8601 vs. RFC 3339 guide. In practice:

"created_at": 1732650000is a raw epoch integer — apply the digit-count check above. "created_at": "2024-11-26T21:00:00Z" is already an RFC 3339 string and is readable as-is, no conversion needed. Some APIs, confusingly, send the number as a string ("created_at": "1732650000") — that’s still an epoch value under the digit-count rule, just quoted, usually because the API author didn’t want a 64-bit integer silently truncated by a client language that only has 53-bit-safe numbers (JavaScript’s Number type, most commonly). If your workflow involves reshaping the response — say, pulling that field into a spreadsheet or a different structured format — the CSV ↔ JSON converterhandles the structural conversion; you’d still run the timestamp values themselves through a dedicated converter afterward.

A quick mental checklist

When you hit an unreadable timestamp in a log or response body: count the digits first (ten, thirteen, sixteen, or nineteen tells you the unit); check whether it’s quoted as a string or a bare number, since that only affects how you extract it, not what it means; and if the same file mixes units, convert per line rather than assuming one resolution for the whole file. None of this requires memorizing conversion factors — it’s pattern recognition you build after doing it a few dozen times, and a converter does the arithmetic either way.