If you are staring at a number like 1700000000 in a log, it is probably epoch time.
The fastest way to debug it is to convert it into a date you can reason about.
Start here:
- Open the Unix Timestamp Converter.
- Paste the value.
- Read the UTC and local time output.
Quick start: the only rule most bugs come from
Most timestamp bugs are unit bugs.
- 10 digits is usually seconds
- 13 digits is usually milliseconds
Example:
1700000000(seconds)1700000000000(milliseconds)
Textavia can auto-detect this, but it helps to know what you are looking at.
What epoch time is
Epoch time (Unix time) is a way to represent a moment as a number.
Most systems define it as:
- seconds since
1970-01-01 00:00:00 UTC
Some systems use milliseconds instead.
Convert timestamp to date (and back)
In the Unix Timestamp Converter, you can:
- convert timestamp -> date
- convert date -> timestamp
- force seconds or milliseconds if auto-detect guesses wrong
Examples
Example 1 (beginner): convert a timestamp from a receipt or email
If you see a timestamp in an export:
- paste it
- check whether it is 10 or 13 digits
- confirm the date matches what you expected
Example 2 (professional): debug an API field
If an API returns createdAt: 1700000000000:
- decode it as milliseconds
- compare it to server logs
If you decode milliseconds as seconds, the date will be far in the future.
Example 3 (professional): debug JWT expiration
JWTs often store exp as seconds.
Workflow:
- decode the token with JWT Decoder
- copy the
expvalue - convert it with the Unix Timestamp Converter
Common mistakes (and the fix)
| Mistake | What you see | Fix |
|---|---|---|
| Seconds vs milliseconds mismatch | a date in 1970 or far in the future | switch units |
| Confusing UTC with local | off by hours | read both UTC and local output |
| Copying a value with spaces or commas | parse error | paste only digits |
| Using an ambiguous date string | wrong conversion | use ISO 8601 (with timezone) |
Troubleshooting
"The date is in 1970"
That usually means:
- you pasted seconds, but the system expected milliseconds
Or your value is 0.
"The conversion is off by hours"
That is a timezone problem.
- UTC is the ground truth
- local time depends on the viewer's time zone
If you are debugging server-side behavior, look at UTC first.
If you only do 3 things
- Check digit count (10 vs 13).
- Compare UTC first; then local.
- Use ISO 8601 with a timezone when converting dates.
Related tools
- Build schedules with Cron Builder.
- Inspect JWT timestamps with JWT Decoder.
Privacy and security
Textavia's timestamp converter runs locally in your browser. Your input is not uploaded to a server.