Understand an unfamiliar timestamp, identify its unit and compare dates without confusing UTC with local display time.
An exported record contains a large number where you expected a date. It may be a Unix timestamp. Before converting it, identify the unit: a value expressed in milliseconds is not interchangeable with the same digits interpreted as seconds.
Know what the number represents
Unix time measures time from the start of 1 January 1970 UTC, conventionally in seconds. Some software interfaces use milliseconds instead. MDN's Unix time explanation provides the underlying reference.
Modern second-based timestamps are commonly around ten digits, while millisecond values are commonly around thirteen. That is a clue, not a substitute for checking the source system's documentation.
Convert a sample and check the display
- Identify whether the source field uses seconds or milliseconds.
- Open the timestamp-to-date tool.
- Enter the value in the unit the tool expects.
- Inspect the displayed date and its time-zone context.
- Compare a record whose real event time you already know.
If the result is wildly implausible, check units before assuming the underlying data is corrupted. When converting the other way, the date-to-timestamp tool needs an unambiguous date and time context.
Keep one reference when comparing systems
A log displayed in UTC and a calendar displayed in local time can describe the same instant with different clock readings. Record the relevant zone when discussing a discrepancy. Daylight-saving changes make manual hour adjustments particularly easy to get wrong.
Use an invented sample or a non-sensitive record while learning. Avoid pasting complete private logs when the timestamp alone is enough to investigate the issue.
Try the converter and keep the unit alongside your exported column name. For user-facing events, read the calendar-link guide; a r37dy account lets you explore the event features available on your plan.