Timestamp conversion examples for seconds, milliseconds, and readable dates
Timestamp conversion looks like a tiny utility, but it shows up constantly in API debugging, log analysis, database checks, and frontend-backend handoff. The time sink is rarely the conversion itself. It is figuring out whether the value is in seconds or milliseconds, which timezone you should trust, and whether you need to convert the result back into a timestamp.
Check whether the value is in seconds or milliseconds first
One of the most common mistakes is treating a 10-digit seconds timestamp as a 13-digit milliseconds timestamp, or the other way around. If the output is decades off, the first thing to inspect is the length of the value.
In JsonDock, checking the digit length and comparing the local and UTC output gives you a fast sanity check before you debug anything deeper.
When to compare UTC versus local time
If you are validating API responses, database records, or server logs, UTC is usually the safer baseline because it removes local environment differences.
If you are debugging what a user or operator sees on screen, local time matters too, because that is the version that affects product behavior and support tickets.
Common two-way conversion workflows
In day-to-day development, a common pattern is converting a timestamp into a readable date to validate an API response, then converting an edited date back into a timestamp for another request.
Another frequent use case is taking timestamps from logs, turning them into readable times, and lining them up against another system to spot latency, sequencing, or timezone mistakes.
FAQ
Most of the time the difference comes from timezone presentation. Use UTC as a baseline first, then compare it with local time for the business context you care about.
If the converted result lands decades too early or too late, check the digit count first. Ten digits usually means seconds and thirteen usually means milliseconds.