Timestamp Converter
Convert between timestamps and human-readable dates
Features
- Bidirectional conversion between Unix timestamps (seconds since 1970-01-01T00:00:00Z) and human-readable dates using the browser's native Date object
- Live current epoch display with one-click refresh, plus formatted output in your browser's locale and ISO 8601 (YYYY-MM-DDTHH:mm:ss.sssZ)
- Quick-jump shortcuts for relative times: 1 hour ago, 1 day ago, 1 week ago, 1 month ago, computed from the moment you click
- Reference timestamps built in: Unix Epoch (Jan 1 1970), Y2K (Jan 1 2000), iPhone release (Jun 29 2007), Bitcoin Genesis Block (Jan 3 2009)
- Accepts standard date formats parsable by Date.parse: ISO 8601, RFC 2822, datetime-local, and many locale strings
- Input validation that distinguishes invalid-timestamp (non-numeric input) from invalid-date (unparseable date) with clear localized messages
- Set Current Date/Time button that pre-fills the date input with the local datetime in datetime-local format and converts immediately
- Copy buttons next to every result, with empty fields and error states excluded so the clipboard never receives stale content
How to use
- To turn a timestamp into a date, paste a 10-digit Unix epoch (seconds) into the Timestamp field; the tool multiplies by 1000 to feed Date().
- To turn a date into a timestamp, type or paste a date in any Date()-parseable format (ISO 8601 like 2026-01-15T10:30:00Z works best) into the Date field.
- Or click 'Current Time' to populate the date field with right-now and see its corresponding epoch.
- Use the Quick Conversions buttons (1 hour/day/week/month ago) to grab relative timestamps for log filtering or cache TTL math.
- Click the copy icon next to a result; output is in your browser's locale plus ISO 8601 for machine use.
- Hit Clear to reset both fields when starting a new conversion.
Tips & Best Practices
- Always specify the timezone when working with timestamps to avoid confusion.
- Use UTC as the standard reference timezone for international applications.
- Double-check daylight saving time transitions when converting dates.
- Bookmark frequently used conversions for faster access.
- Copy results directly into your code or configuration files.
FAQ
Seconds or milliseconds — which Unix timestamp does this tool expect?
This tool uses Unix timestamps in seconds (10 digits for current dates, e.g., 1735689600), which is the POSIX standard used by C time(), Linux, MySQL UNIX_TIMESTAMP(), and most APIs. JavaScript's Date.now() and many JSON APIs use milliseconds (13 digits). If you have a 13-digit number, divide by 1000 before pasting, or paste the date string directly into the Date field.
How are timezones handled?
Unix timestamps are inherently UTC — the same instant regardless of timezone. When converting timestamp to date, the output uses your browser's local timezone via toLocaleString(), and the ISO field shows the equivalent UTC. When converting date to timestamp, ambiguous strings (e.g., '2026-01-15') are parsed as your local timezone, while ISO strings ending in Z or an offset (+02:00) are unambiguous. Always include the offset for cross-system reliability.
What's the Unix epoch and why January 1, 1970?
The Unix epoch is 1970-01-01T00:00:00Z, chosen by Bell Labs as a convenient round number near the time Unix was being designed in 1969-1971. Timestamp 0 is that exact moment, and timestamps count seconds elapsed since (negative values are pre-1970). Almost all modern operating systems and programming languages count from this same epoch, making it the lingua franca of time in computing.
What about the Year 2038 problem?
Systems that store Unix timestamps as a signed 32-bit integer overflow at 03:14:07 UTC on 19 January 2038 (timestamp 2147483647), wrapping to a negative number representing 1901. JavaScript and modern 64-bit systems use 64-bit numbers and are safe for ~292 billion years. If you're auditing legacy C, MySQL TIMESTAMP columns, or embedded firmware, plan migrations to 64-bit time_t or millisecond Unix time before 2038.
Can I convert a timestamp to ISO 8601 specifically?
Yes — after converting, the tool also displays the ISO 8601 form via Date.toISOString(), which is YYYY-MM-DDTHH:mm:ss.sssZ in UTC. ISO 8601 is the only format you should send across system boundaries: it's unambiguous, sortable as a string, and supported natively by JavaScript, Python's fromisoformat, Postgres TIMESTAMPTZ, and virtually every modern API. Avoid US-style 'MM/DD/YYYY' or European 'DD/MM/YYYY' for inter-system data.
Why does my date string return an invalid-date error?
Date.parse is forgiving but not consistent across browsers for non-ISO formats. Reliable inputs are ISO 8601 ('2026-01-15T10:30:00Z'), the datetime-local format ('2026-01-15T10:30'), and full RFC 2822 ('Thu, 15 Jan 2026 10:30:00 GMT'). Avoid bare formats like '15/01/2026' (ambiguous) or 'Jan 15' (no year). If you have a custom format from a log file, normalize it to ISO 8601 first.
Does this work for SQL timestamps and database fields?
Yes, with a caveat: most SQL servers store TIMESTAMP/DATETIME without timezone info, so what you see in a column is wall-clock time relative to the server's session timezone. Convert by appending the server's offset (e.g., '2026-01-15 10:30:00+00') before pasting. PostgreSQL TIMESTAMPTZ, MySQL TIMESTAMP (which is stored as UTC internally), and SQLite all play nicely with ISO 8601.
Is anything sent to a server?
No. All conversions use the browser's built-in Date constructor and Math.floor — there's no network call involved. The current-time clock reads from your device's system time. You can verify via DevTools Network tab; the tool runs purely client-side and works fully offline once loaded.