Every API response, database row and log line seems to include a number like 1754640000. That's a Unix timestamp — the seconds since January 1, 1970, UTC. This guide explains what timestamps are, the classic seconds/milliseconds trap, and how to convert them to human-readable dates (and back) without guessing.
What Is a Unix Timestamp?
A Unix timestamp counts seconds (or milliseconds) since the Unix epoch: 1970-01-01 00:00:00 UTC. Because it's defined in UTC, the same timestamp means the same instant everywhere — only the displayed local time differs. That's why timestamps are the safest way to store times across time zones.
The Seconds vs. Milliseconds Trap
JavaScript and many databases use milliseconds (13 digits), while most Unix tools and APIs use seconds (10 digits). Get them mixed up and your date is off by a factor of 1000 — roughly 11.6 days for every second of error. A quick rule of thumb:
- 10 digits ≈ seconds (e.g.
1754640000= 2025-08-08) - 13 digits ≈ milliseconds (e.g.
1754640000000= the same instant)
Auto-detection by digit count is exactly what the converter does when you don't specify the unit.
Local Time vs. UTC
A timestamp converts to the same instant but a different wall-clock time per time zone: 1754640000 is 2025-08-08 12:00 UTC and 2025-08-08 20:00 in UTC+8. Converters show both views — UTC and your local time — so you can read either.
How to Convert Timestamps Online
- Open the tool: go to the timestamp converter.
- Paste the timestamp: seconds or milliseconds — auto-detected by length, or choose the unit manually.
- Read the date: see UTC and your local time, plus the weekday.
- Go the other way: pick a date and time to get its timestamp in seconds and milliseconds.
- Use the live clock: the current timestamp is always displayed for reference.
Tip: when debugging an API, confirm which unit the docs specify. If you see a date 11.6 days off, you've almost certainly mixed seconds and milliseconds.
Frequently Asked Questions
Storing Timestamps the Right Way
Almost every timestamp bug traces back to one of two storage mistakes: saving local wall-clock time instead of UTC, or leaving the unit ambiguous. The fix is a convention, not cleverness — store every timestamp as UTC, convert to local time only at display, and name the unit in the field or column (created_at_ms beats created_at that might be either). A database mixing seconds from one service and milliseconds from another produces records that appear to date from 1970 or from five centuries out; both are the same unit mismatch wearing different costumes.
The converter is also the fastest way to audit an existing dataset: paste a suspicious value, and whether it reads as January 1970 or as a date five hundred years away tells you instantly which unit the source was using.
Edges Worth Knowing
Values before 1970 are legal — they are simply negative numbers counting backwards from the epoch, and the tool converts them correctly. Precision beyond milliseconds exists in some systems (microseconds and nanoseconds for performance logging), and the same digits misread as milliseconds will land centuries off, so verify the source's unit before trusting a conversion. And because Unix time ignores leap seconds, a timestamp is best understood as "seconds since the epoch as computers count them" — a nuance that only matters in systems tracking sub-second legal time.
What is the current Unix timestamp?
The converter shows it live. At any moment it's the seconds elapsed since 1970-01-01 UTC — currently around 1.78 billion and counting.
Why is my timestamp converting to the wrong date?
Almost always a seconds/milliseconds mismatch. If the date looks about 11.6 days off per unit, multiply or divide by 1000.
Is 1970-01-01 significant?
It's the Unix epoch — a convention, not a calendar event. Negative timestamps represent dates before 1970 and are valid too.
Is my timestamp uploaded when I convert it?
No. The timestamp converter computes locally in your browser.
Should I store timestamps in UTC?
Yes, without exception. Local wall-clock time changes with DST transitions and differs across your users, so a stored local time is ambiguous the moment it leaves one machine. Store UTC, render local — every mature system does this.
What about dates before 1970?
They are negative timestamps and convert normally: -86400 is one day before the epoch. Historical dates before the modern calendar era need dedicated libraries, but anything from the 20th century onward works directly.
Do Unix timestamps count leap seconds?
No — the Unix scale treats days as exactly 86400 seconds and lets real UTC leap seconds be absorbed invisibly. For everyday scheduling this is irrelevant; for systems that must track legal time to the exact second, it is a documented limitation.
References
- Unix time — Wikipedia: https://en.wikipedia.org/wiki/Unix_time
- Date and time handling — MDN Web Docs: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date