What a Unix timestamp converter does
A Unix timestamp converter translates between the plain number that computers store, such as 1767225600, and a date a person can read, such as January 1, 2026 at midnight UTC. Unix time counts the seconds since 00:00:00 UTC on January 1, 1970, the "epoch". Because it is a single number with no time zone attached, it is how databases, APIs, log files and tokens record when something happened. The catch is that nobody can read it at a glance, and the same number looks different depending on the zone and unit you assume.
How to convert a timestamp
- Paste the timestamp into the first box. Commas, spaces and underscores are ignored, so
1,767,225,600works. You can also paste an ISO date string to go the other way. - Check the detected unit. Ten digits means seconds, 13 milliseconds, 16 microseconds and 19 nanoseconds. Override it with the unit menu if your value is unusual, such as a date in the 1960s stored in milliseconds.
- Read the result in your local time, UTC, ISO 8601, RFC 2822, a relative phrase like "3 days ago", and any other IANA time zone you pick.
- Convert back by choosing a date, time and the zone that date belongs to. The tool handles daylight saving time and warns you when a local time does not exist, like 2:30 AM on the night clocks spring forward.
- Batch convert a column of values from a log or spreadsheet, then copy the results as CSV.
Seconds, milliseconds and microseconds
Different systems count at different resolutions, and mixing them up is the most common timestamp bug. Unix tools, PHP, MySQL and JWT claims use seconds. JavaScript and Java use milliseconds. Python's time.time() returns seconds with a fraction, and PostgreSQL and many tracing systems work in microseconds. If a date comes out in January 1970, you probably passed seconds where milliseconds were expected; if it lands tens of thousands of years in the future, you did the opposite.
1767225600 seconds 2026-01-01T00:00:00Z 1767225600000 milliseconds 2026-01-01T00:00:00Z 1767225600000000 microseconds 2026-01-01T00:00:00Z
Time zones and daylight saving
A timestamp is the same instant everywhere. Time zones only come into play when you format it. That is why the safest pattern is to store UTC timestamps and convert to the viewer's zone at the last moment. Use IANA names like America/Chicago rather than fixed offsets like -06:00, because the offset changes twice a year and the IANA database knows when.
Watch out for how JavaScript parses strings. new Date('2026-03-08') is treated as UTC midnight, but new Date('2026-03-08T02:30') is treated as local time, and on a DST change night that local time may not exist. Always include a Z or an offset when you mean a specific instant:
new Date('2026-03-08T02:30:00Z').getTime() / 1000; // unambiguous
new Date('2026-03-08T02:30:00-05:00').getTime() / 1000; // unambiguous
new Date('2026-03-08T02:30').getTime() / 1000; // depends on the machine
Common mistakes
Off-by-1000 in tokens and APIs
JWT exp and iat claims must be in seconds, but Date.now() gives milliseconds. If a token is rejected right after it is issued, decode it with the JWT decoder and check the claim length.
Zero-based months
In JavaScript, new Date(2026, 0, 1) is January 1. Passing 1 for January gives you February.
MySQL TIMESTAMP versus DATETIME
MySQL's TIMESTAMP column converts to and from the session time zone and stops at 2038-01-19. DATETIME stores the wall-clock value as given, with no zone conversion, up to the year 9999. Pick one deliberately, and set the connection time zone to UTC so stored values do not drift between servers.
The year 2038 problem
Signed 32-bit Unix time overflows at 2147483647, which is 03:14:07 UTC on January 19, 2038. Modern 64-bit systems are fine, but embedded devices, old file formats and 32-bit database columns still break. Try the value in the converter to see the exact moment.
Scheduling jobs around a specific time? The cron expression builder previews the next run times in your zone. And when timestamps arrive inside an API response, the JSON formatter makes them easier to pick out before you paste them into the batch box.
Frequently asked questions
What is a Unix timestamp?
A Unix timestamp, also called epoch time, is the number of seconds that have passed since 00:00:00 UTC on January 1, 1970, not counting leap seconds. It is the same number everywhere in the world at the same instant, which makes it a reliable way to store and compare times.
How do I tell if a timestamp is in seconds or milliseconds?
Count the digits. A current timestamp in seconds has 10 digits, in milliseconds 13, in microseconds 16 and in nanoseconds 19. This converter detects the unit automatically, and you can override it if you are working with very old or far-future dates.
Does a Unix timestamp have a time zone?
No. A timestamp always counts from midnight UTC and represents a single instant. Time zones only matter when you display it as a calendar date and clock time, which is why the same timestamp shows different local times in New York and London.
What is the year 2038 problem?
Systems that store Unix time as a signed 32-bit integer can count only up to 2147483647, which is 03:14:07 UTC on January 19, 2038. One second later the value overflows to a negative number and dates jump back to 1901. Using 64-bit integers, as modern languages and databases do, avoids it.
How do I get the current Unix timestamp in JavaScript?
Use Math.floor(Date.now() / 1000) for seconds. Date.now() on its own returns milliseconds, which is what JavaScript Date objects use internally.