Unix time for logs, APIs and cross-team debugging
A Unix timestamp counts seconds (or milliseconds) from the epoch midnight 1970-01-01 UTC. That convention is boring on purpose: it lets servers in different regions agree on an instant without emailing timezone names back and forth. You see epochs in JWT exp claims, S3 object metadata, Kafka message headers, database TIMESTAMP WITH TIME ZONE serialisations in some drivers and in nearly every mobile analytics pipeline. The pain arrives when one service emits seconds, another emits milliseconds and a third prints ISO-8601 strings only in local office time. This guide frames how to read timestamps consistently, how to avoid classic off-by-three-orders-of-magnitude mistakes and which companion tools on Datamata close the loop when your investigation mixes spreadsheets, SQL and JSON.
Seconds
Typical in Linux date +%s, Postgres EXTRACT(EPOCH …) and many REST APIs.
Milliseconds
Date.now(), browser performance APIs and several mobile SDKs.
ISO-8601
Human-readable wire format; best for logs you paste into tickets and docs.
Time zones: UTC as the hub
Epoch integers are always interpreted relative to UTC when you convert to civil calendars, even if your laptop’s local zone is set elsewhere. When a product bug report says “the event happened at 3pm”, insist on a time zone or an ISO string with offset. Convert to UTC first, then compare integers. That discipline prevents daylight-saving ambiguities from masquerading as data bugs. If you need recurring wall-clock rules after you have a concrete instant, use the Cron Expression Builder separately — cron expresses schedules, not instants.
Pairing with JWT and JSON workflows
Security tokens almost always carry exp and iat as numeric epochs. Paste the token into the JWT Decoder, copy exp into this converter and compare with your server’s skew budget. For JSON log lines that nest timestamps inside objects, pretty-print with the JSON Formatter before you copy fields so you do not grab the wrong nesting level.
Spreadsheet and warehouse hand-offs
Finance and operations teams sometimes export “numbers that look like dates” that are actually Excel serials. Engineers expect Unix seconds. If your column looks like 45292.75, switch tools to the Excel Serial Date Converter. If you are writing SQL that casts strings to timestamps, prototype expressions in the SQLite Playground with a few sample literals before you run wide updates in production.
A practical interpretation checklist
When a timestamp looks wrong, resist timezone guessing and instead validate the input model. First confirm whether it is seconds or milliseconds, then convert a known sample instant and compare to an external reference (a build log, a public time API output or an incident timeline). Next check for rounding: some systems store sub-second precision in a separate field, so you may need to combine columns before you compare. Finally verify whether the value is meant to be UTC or local wall time; if the producer wrote local time into a field called “epoch”, treat it as malformed data until corrected. If you embed these values inside JWT payloads or share links, decode or parse them first with the dedicated tools so you reduce the number of implicit assumptions in your workflow.