Guides / 4 min read
Reading Unix Timestamps In Logs Without Guesswork
Most timestamp confusion comes from unit mismatches and time zone assumptions. Converting them carefully saves time during incidents.
The seconds vs milliseconds trap
Unix timestamps often appear as 10-digit seconds or 13-digit milliseconds. Mixing the two is one of the fastest ways to misread event order during an incident.
If a converted value lands decades away from the expected date, the unit is usually wrong rather than the event itself.
- 10 digits usually means seconds.
- 13 digits usually means milliseconds.
- Always confirm the unit before comparing timestamps across systems.
Time zones still matter
A correct conversion can still be misleading if one dashboard shows UTC and another shows local time. During debugging, align systems to the same time zone whenever possible.
When you share incident timelines, include the zone or offset explicitly so teammates do not reinterpret the sequence differently.
Where timestamp conversion helps most
Timestamp tools are especially useful when reading logs, validating token expiration, comparing database rows, or checking scheduled job execution times.
A quick readable date often reveals whether a problem is a stale token, a delayed worker, or simply a display mismatch.