Why epoch time is everywhere
Databases, APIs, log files, message queues, JWT claims, and schedulers often represent time as a single integer. That integer is compact and timezone-neutral, but it is hard for humans to read during debugging. A timestamp converter turns the integer back into the dates developers actually reason about.
The most common bug is mixing seconds and milliseconds. JavaScript uses milliseconds inDate.now(), while many APIs store seconds. This tool accepts both formats and shows local and UTC output side by side.
Examples to test
0converts to the Unix epoch: January 1, 1970 at 00:00:00 UTC.- A 10-digit value such as
1710000000is interpreted as seconds. - A 13-digit value such as
1710000000000is interpreted as milliseconds.
Practical debugging uses
- Checking JWT
expandiatclaims. - Reading database rows that store created-at values as epoch integers.
- Comparing server logs from systems in different timezones.
- Confirming scheduled job windows before a release.
Frequently asked questions
What is a Unix timestamp?
A Unix timestamp is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970. Many JavaScript systems use milliseconds instead of seconds.
How do I know if a timestamp is seconds or milliseconds?
Current timestamps in seconds are about 10 digits long. Current timestamps in milliseconds are about 13 digits long. This tool detects both formats automatically.
Why do local time and UTC differ?
UTC is the global reference time. Local time applies your browser's timezone offset, so it may differ by several hours depending on where you are.
Is anything uploaded?
No. Timestamp conversion uses JavaScript Date objects in your browser and does not send values anywhere.
Related tools
- Unix Timestamps Explained for a deeper guide to seconds, milliseconds, UTC, and local time.
- JSON Formatter for inspecting timestamp fields in API payloads.
- URL Encoder/Decoder for debugging timestamp values in query strings.