An API response says an event happened at 1700000000. A browser console shows a different-looking date. A database export shows another value with three extra zeros. Before assuming one system is broken, check the units and display zones. Unix time makes event order easier to compare, but only when every part of the workflow agrees on what a number means.
Here is a practical routine for developers reviewing an epoch timestamp in an API, analytics export, or log.
Start with the documentation for the field. Does it say seconds since the Unix epoch, milliseconds since the epoch, or an ISO-formatted date string? The name alone may help, but an explicit contract is better. A field called timestamp can mean different things across systems.
If the source is undocumented, record your assumption instead of building a permanent fix around a guess. Use a known event to test whether the interpretation is plausible, then confirm the unit with the producer of the data.
JavaScript Date.now() and Date.prototype.getTime() report milliseconds since January 1, 1970, at 00:00:00 UTC. Many APIs use seconds. If an API gives you whole seconds, multiply by 1,000 before passing the number to new Date(number). If you divide a JavaScript millisecond value by 1,000 for an API that expects seconds, confirm whether it accepts fractional seconds or requires a whole number.
For example, 1700000000 seconds and 1700000000000 milliseconds identify the same moment. If the date appears close to 1970, treating seconds as milliseconds is a likely cause. A timestamp far outside the expected range may indicate the reverse mistake.
A Unix timestamp represents an instant without embedding a user's time zone. When a browser displays it locally, the wall-clock hour can change while the event remains the same. In a debugging report, include the raw value, its unit, and an unambiguous UTC date and time. Add a local display only when the user's zone is relevant.
Date strings need extra care. An ISO string with Z explicitly denotes UTC; a date and time without an offset may be interpreted in a local zone by some parsing workflows. Different systems can also handle nonstandard date strings differently. Prefer explicit offsets or a clear UTC marker at the boundary between systems.
Do not assume a timezone offset copied from today's settings applies to an older or future event. Local offset rules can change with daylight saving transitions and historical policy. When a report needs the event's local time, use the intended location and event date, then record the UTC equivalent for comparison.
When you investigate an incident, gather the timestamp from each system and normalize their units before sorting. Note whether one log is showing UTC and another is showing local time. If values include milliseconds, retain that precision when ordering events that happened within the same second.
Elapsed time is another useful check. Subtract two timestamps only after expressing them in the same unit. If the result looks implausible, verify units and clock configuration before concluding the events were recorded in the wrong order.
Open Epochly's free Unix timestamp converter when you need a quick human-readable check during debugging. Use it to confirm a suspected seconds-versus-milliseconds error or compare a UTC result with a local view. A good converter does not replace a field contract; it helps you catch the moment when two systems are talking about the same instant in different ways.
