About Unix Timestamps
A Unix timestamp is the number of seconds that have elapsed since midnight UTC on January 1, 1970 — a moment known as the epoch. That date was chosen when the original Unix operating system was being built, and it has stuck ever since. Almost every programming language, database, and operating system represents time internally as some form of this number, because an integer is unambiguous: no timezone confusion, no daylight-saving surprises, no locale-dependent formatting.
The catch is that integers are unreadable to humans. 1735689600 means nothing at a glance, but the moment you convert it you see January 1, 2025, 00:00 UTC. This tool moves back and forth between the two representations so you can read what a log line actually says, debug a scheduled job, or build a timestamp into a test fixture.
Many systems use seconds, but some — JavaScript, most NoSQL databases, some APIs — use milliseconds instead. A 10-digit number is almost certainly seconds; a 13-digit number is almost certainly milliseconds. This tool handles both so you do not have to guess.
How to Convert Timestamps
- Paste a Unix timestamp (seconds or milliseconds) to convert it to a human-readable date, or pick a date and time to convert it to a timestamp.
- The result appears in both UTC and your local timezone, which makes it easy to sanity-check a log entry against the clock on your laptop.
- Copy whichever format you need with the copy button.
Examples
A timestamp in seconds
Input
1735689600
Output
2025-01-01T00:00:00Z
The same moment in milliseconds
Input
1735689600000
Output
2025-01-01T00:00:00Z
10 digits is seconds; 13 digits is milliseconds. Pasting either produces the same human-readable date.
A date in local time vs UTC
Input
2025-07-01 09:00 (in Asia/Taipei, UTC+8)
Output
2025-07-01T01:00:00Z (UTC) / 1751331600 (seconds)
Same moment, two representations. Always record the timezone alongside any human-readable timestamp.
Common Use Cases
- Reading a timestamp from an application log or an API response.
- Generating a fixed timestamp for a test case or database seed.
- Debugging a scheduled job by converting a scheduled_at column to a wall-clock time.
- Calculating time differences — two timestamps can be subtracted directly to get a duration in seconds.
Tips
- When a system stores time, prefer UTC. Store and transmit timestamps as UTC; convert to a user's local timezone only for display.
- The year 2038 matters: 32-bit signed second-based timestamps overflow on January 19, 2038. Most modern systems use 64-bit integers and are fine, but legacy systems may break — worth checking if you maintain one.
- Beware daylight-saving transitions when doing human-friendly date math. Adding '24 hours' and adding 'one day' can produce different results twice a year.
Frequently Asked Questions
Seconds or milliseconds — how do I tell them apart?
By digit count. A second-based timestamp for a date in the current decade is 10 digits; a millisecond-based one is 13. If in doubt, try both and see which gives a plausible date.
What is the year 2038 problem?
32-bit signed integers can represent up to 2,147,483,647 seconds past the epoch, which is January 19, 2038 at 03:14:07 UTC. Systems that store timestamps as 32-bit integers will overflow at that moment. Modern 64-bit systems are not affected, but some embedded devices and legacy databases still are.
Why is the epoch January 1, 1970?
It was a recent, round date when the original Unix timekeeping code was written in the early 1970s — the developers picked a convenient point in the past that every living user was born after.
Is my input sent to a server?
No. The conversion runs entirely in your browser.