Timestamp Converter
What This Calculator Does
This timestamp converter translates between Unix epoch timestamps and human-readable dates. In "Timestamp to Date" mode, you enter a Unix timestamp (seconds since January 1, 1970 UTC) and get the corresponding date, time, and ISO 8601 representation. In "Date to Timestamp" mode, you enter a date and time and receive the Unix timestamp in both seconds and milliseconds.
Inputs Explained
- Unix Timestamp (Timestamp to Date mode): An integer representing the number of seconds elapsed since January 1, 1970 00:00:00 UTC (the Unix epoch). Example: 1672531200 represents January 1, 2023.
- Date & Time (Date to Timestamp mode): A human-readable date and time input in your local datetime format.
How It Works
Unix time is a system for tracking time as a running total of seconds from a fixed point: midnight UTC on January 1, 1970, known as the Unix epoch. This system is used extensively in programming, databases, APIs, and file systems. The converter applies simple multiplication (seconds × 1000 for milliseconds) and JavaScript's built-in Date object to translate between the two representations.
Formulas Used
Date = Unix Epoch + (Timestamp × 1 second)
Timestamp (seconds) = (Date − Unix Epoch) ÷ 1 second
Timestamp (milliseconds) = Timestamp (seconds) × 1000
Timestamp (seconds) = (Date − Unix Epoch) ÷ 1 second
Timestamp (milliseconds) = Timestamp (seconds) × 1000
Step-by-Step Example: Timestamp to Date
Input Timestamp: 1769904000
Step 1: Start from January 1, 1970 00:00:00 UTC.
Step 2: Add 1,769,904,000 seconds.
Result: February 1, 2026 00:00:00 UTC. ISO 8601: 2026-02-01T00:00:00.000Z.
Step-by-Step Example: Date to Timestamp
Input Date: January 31, 2026, 12:00:00 PM local time
Step 1: Convert to UTC based on local timezone offset.
Step 2: Calculate seconds since the Unix epoch.
Result: Unix timestamp depends on your local time zone offset.
Use Cases
- Software development: Debug timestamps in log files, database records, or API responses.
- System administration: Interpret file modification times or cron job schedules stored as epoch values.
- Data analysis: Convert timestamp columns in CSV files to human-readable dates for reporting.
- API testing: Generate or verify timestamp parameters when testing REST or GraphQL endpoints.
- Digital forensics: Interpret timestamps from file metadata, browser histories, or system logs.
Assumptions and Limitations
- Unix timestamps are integers representing seconds since Jan 1, 1970 UTC. Negative values represent dates before the epoch.
- The converter distinguishes between seconds (10-digit) and milliseconds (13-digit) timestamps automatically.
- JavaScript's Date object can represent dates from April 20, 271821 BCE to September 13, 275760 CE.
- Leap seconds are not represented in Unix time — the Unix clock does not count leap seconds.
- The "Date to Timestamp" mode uses your browser's local time zone unless otherwise specified.
Frequently Asked Questions
A Unix timestamp is the number of seconds that have passed since 1 January 1970 at 00:00:00 UTC, also called the "Unix epoch". So a timestamp like 1746604800 represents a specific moment in time — you just count that many seconds from the epoch. It's used everywhere in software because it's a single number with no time zone, no formatting issues and no ambiguity. Unix time skips leap seconds, which keeps it simple but means it's not a perfect physics-grade time scale. For everyday programming, that's a fine trade-off.
Paste the seconds value into the converter and it adds them to the Unix epoch (1 January 1970, 00:00:00 UTC) to get the actual moment in time. The tool then displays that as a readable date, usually in both UTC and your local time zone. So 1700000000 converts to 14 November 2023, 22:13:20 UTC. If your timestamp has 13 digits instead of 10, it's almost certainly in milliseconds — divide by 1000 first or use a converter that auto-detects the unit. Both formats are common in APIs.
Pick "Date to Timestamp" mode in the converter, enter your date and time, and choose the time zone (UTC is the safest default for storing). The tool counts the seconds from 1 January 1970 UTC up to that moment and gives you the result. So 1 January 2025 at 00:00 UTC works out to 1735689600. Most converters also show you the milliseconds version (just multiply by 1000), since some APIs and JavaScript's Date object expect that. Always be explicit about the time zone, or you'll get answers off by hours.
A 10-digit Unix timestamp counts seconds since the epoch, while a 13-digit one counts milliseconds. So 1700000000 (seconds) and 1700000000000 (milliseconds) point to the same moment. Languages and platforms differ — Unix command line, PHP and Python's time() use seconds; JavaScript's Date.now() and many web APIs use milliseconds. To convert milliseconds to seconds, just divide by 1000. If you're staring at a number and not sure what it is, count the digits — anything around 10 is seconds (current era), anything around 13 is milliseconds.
A 13-digit number is almost always a millisecond timestamp — common in JavaScript, MongoDB and many web APIs. If your converter only accepts seconds, divide the number by 1000 first and use the result. So 1700000000000 ms becomes 1700000000 seconds, which converts to 14 November 2023, 22:13:20 UTC. Better still, use a converter that handles both formats automatically — most modern ones do. If you accidentally treat ms as seconds, you'll get a date thousands of years in the future, so always check the result looks sensible.
No — Unix time uses uniform POSIX seconds and skips leap seconds entirely. A leap second is an extra second occasionally added to UTC to keep atomic time aligned with Earth's slowing rotation. When one happens, Unix time either repeats a second or smears it gradually (Google does this), depending on the system. For everyday work — timestamps in apps, databases, logs — this doesn't matter. It only matters for precise scientific timing, satellite work or financial systems where sub-second accuracy across decades is critical. Most software just ignores leap seconds.
The Unix operating system was being developed in the late 1960s and early 1970s, and the team needed a reference point for measuring time. They picked 1 January 1970 at 00:00 UTC because it was a clean, recent, easy-to-remember date — close enough to the present that timestamps wouldn't be huge numbers, but firmly in the past so all "current" times would be positive. There's no deeper meaning to it. The choice has stuck for over 50 years and is now baked into virtually every operating system, programming language and database in the world.
Most converter tools have a "current timestamp" or "now" button — click it and the tool reads your system clock, converts to UTC and shows the result in seconds (and usually milliseconds too). On a Linux or Mac terminal you can run date +%s. In Python, time.time() gives you seconds with decimal precision. In JavaScript, Date.now() returns milliseconds. The current timestamp updates every second, so don't be surprised if you see slightly different values across tabs — they're all correct, just a moment apart. Useful for logging events or generating unique IDs.
Epoch time in milliseconds is the number of thousandths of a second that have passed since the Unix epoch (1 January 1970, 00:00:00 UTC). It's the same idea as a regular Unix timestamp but with 1000× more precision. So if a Unix timestamp is 1700000000 seconds, the millisecond version is 1700000000000. To convert from seconds, multiply by 1000; to go the other way, divide by 1000. JavaScript uses milliseconds by default, which is why web APIs often expect this format. It's better for measuring short intervals like response times.
APIs use timestamps for almost everything — recording when a record was created, sorting events in order, expiring authentication tokens, filtering data by date range, and tracking when something was last updated. The format varies: some APIs use Unix seconds, others use milliseconds, and many use ISO 8601 strings like "2026-05-07T14:30:00Z". Always check the documentation to see what format is expected, and watch out for time zone assumptions. When you store timestamps in a database, UTC is the safest choice — convert to local time only when displaying to the user.
Sources and References
- The Open Group Base Specifications – Unix Time — Official POSIX specification defining Unix epoch time and the seconds-since-epoch convention.
- RFC 3339 – Date and Time on the Internet — IETF standard for timestamps on the internet, closely related to ISO 8601.
- ISO 8601 Date and Time Format — The international standard for date and time representation.
- MDN Web Docs – JavaScript Date — Reference for JavaScript's Date object used in the conversion logic.
- Schema.org FAQPage Specification — Structured data standard for the FAQ markup on this page.