Unix Timestamp Converter
Convert Unix epoch time to readable dates and back — seconds or milliseconds, UTC and local, entirely in your browser.
- Runs in your browser
- No upload, no tracking
- Free forever
How it works
A Unix timestamp converter translates between epoch time — the number of seconds (or milliseconds) since January 1, 1970 UTC — and human-readable dates, in both directions. It is essential for reading the timestamp columns and logs that databases and APIs store, showing the same instant as a Unix value, ISO 8601, UTC, your local time and a relative "x ago" label. This tool runs entirely in your browser and is built by JusDB, a managed database operations team.
- 1
Timestamp to date
Paste a Unix timestamp into the left panel, or hit Now to load the current epoch. Toggle the unit between seconds and milliseconds to match your source.
- 2
Read every representation
The result lists Unix seconds, Unix milliseconds, ISO 8601, UTC, your local time and a relative label — copy any row with one click.
- 3
Date to timestamp
In the right panel, type a date string like an ISO 8601 value or use the datetime picker to get the matching Unix timestamp back.
- 4
Copy what you need
Click copy on any output row to send it to your clipboard. Everything runs on the browser's native Date APIs — nothing is uploaded.
Frequently asked questions
- What is a Unix timestamp?
- A Unix timestamp (also called epoch time) is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC. It is widely used in programming to represent points in time in a compact, timezone-independent format.
- What is the difference between seconds and milliseconds timestamps?
- Most Unix APIs return timestamps in seconds (10 digits for current time). JavaScript's Date.now() returns milliseconds (13 digits). Use the unit toggle to tell the tool which one your input uses.
- What timezone does the converter use?
- The tool shows both UTC (timezone-independent) and Local time (your browser's timezone). The ISO 8601 output is always in UTC.
- Can I convert a date string back to a timestamp?
- Yes. The right-hand panel accepts a date/time string (such as an ISO 8601 value or "Jan 15 2024") or a datetime-local picker, and returns the matching Unix timestamp in both seconds and milliseconds.
- What date formats does the converter accept?
- It uses the browser's native Date parser, which reliably handles ISO 8601 (e.g. 2024-01-15T12:00:00Z). Other free-form formats may parse inconsistently across browsers, so prefer ISO 8601 for unambiguous results.
- Is any data sent to a server?
- No. All conversions use JavaScript's built-in Date APIs and run entirely in your browser. Nothing is sent to JusDB or anywhere else.
Understanding Unix time, the 2038 problem, and how databases store it
Epoch time is deceptively simple: a single integer counting elapsed seconds from the Unix epoch, 1970-01-01T00:00:00Z. Because it is just a number with no timezone and no ambiguity, it has become the lingua franca for moving instants between languages, services, and storage engines. The friction starts when that number meets human calendars, varying precision, and the way each database chooses to persist it.
Seconds, milliseconds, and microseconds
A current epoch value is 10 digits in seconds (around 1.7 billion), 13 digits in milliseconds, and 16 digits in microseconds. Most Unix system calls and many APIs speak seconds, while JavaScript's Date works in milliseconds and Postgres internally keeps microsecond precision. Mixing units is the classic bug: a millisecond value read as seconds lands roughly 50,000 years in the future. When a date looks wildly wrong, count the digits before anything else.
The Year 2038 problem
Systems that store epoch seconds in a signed 32-bit integer overflow at 03:14:07 UTC on 19 January 2038, wrapping to a negative number and jumping back to 1901. This affects legacy C code, some embedded firmware, and older database columns sized as 4-byte integers. Modern stacks use 64-bit time, which pushes the limit hundreds of billions of years out, but auditing any homegrown integer time column for its width is worthwhile before 2038 arrives.
Timezones, UTC, and ISO 8601
The durable rule is to store and compute in UTC and convert to local time only at the display edge. Epoch values are inherently UTC, which is half their appeal. When you do need a string, ISO 8601 (for example 2024-01-15T12:30:00Z, where the trailing Z means UTC) is unambiguous and sorts lexicographically in chronological order — a free win for logs and filenames. Avoid locale-formatted strings in storage; they parse inconsistently across runtimes.
How databases actually store it
In PostgreSQL, prefer timestamptz over timestamp: despite the name, timestamptz does not store a zone — it normalizes the input to UTC on write and converts to the session timezone on read, so two clients in different regions always agree on the instant. Plain timestamp stores wall-clock digits with no zone context and is a frequent source of off-by-hours bugs.
In MySQL, TIMESTAMP is epoch-based and auto-converts to and from UTC using the connection timezone (and historically carried the 2038 limit), while DATETIME stores the literal value with no conversion. Some teams instead store a raw BIGINT epoch: it is portable and conversion-free, but you lose date arithmetic, range queries read poorly, and indexes give up native interval logic. Native timestamp types keep the database time-aware; integer epochs trade that away for simplicity.
Rule of thumb: store UTC (timestamptz or epoch), transmit ISO 8601, and convert to local time only in the UI. For migration war stories and schema patterns, see the JusDB blog.