What is Date and Time Converter?
A Date and Time Converter converts data from one format to another using a deterministic mapping. It parses the input, transforms it according to the relevant standard, and returns a ready-to-use result. Parse any common date string (ISO 8601, Unix timestamp, US, EU, long) and emit it in every other format simultaneously.
Date and Time Converter
Convert between ISO 8601, Unix timestamp, US, EU, and long date formats. Handles timezones.
TLDR
Type any date or timestamp (ISO 8601 like 2026-05-15T12:30:00Z, Unix epoch like 1758844800, or natural like 'May 15, 2026'). The page parses with Date and emits in every standard format including UTC, local, ISO, RFC 2822, Unix seconds, Unix milliseconds.
How to use this tool
- Enter your inputs. Each field is labeled with what it expects.
- Read the result instantly. Numbers update as you type or change inputs.
- Adjust to test sensitivity. Change one input at a time to see what moves the result most.
- Cross-check the formula in the section below if you want to verify the math.
- Copy or screenshot the result for later. The site does not save anything; close the tab and inputs are gone.
About this tool + how it works
This tool runs 100% in your browser - the libraries load from a public CDN and the math runs on your device. Nothing is uploaded to a server. The underlying logic is:
d = new Date(input)
out = { iso, utc, local, unix_s, unix_ms, rfc2822, long }
You can verify by opening the browser developer tools and watching the Network tab; you'll see no requests fired during normal use beyond the initial page and library load.
The main date and time formats
A single moment in time can be written many ways, and APIs, logs, databases, and spreadsheets each prefer a different one. This converter takes any recognizable date or time and shows it in all the common representations at once, so you can copy whichever a given system expects without doing the math by hand.
| Format | Example | Where it is used |
|---|---|---|
| ISO 8601 | 2026-05-28T14:30:00Z | APIs, JSON, databases |
| Unix seconds | 1779892200 | Logs, programming, epoch math |
| Unix milliseconds | 1779892200000 | JavaScript, event timestamps |
| RFC 2822 | Thu, 28 May 2026 14:30:00 GMT | Email headers, HTTP |
| Local / human | May 28, 2026, 2:30 PM | UI display, reports |
Understanding Unix time and UTC
Unix time is the number of seconds elapsed since the Unix epoch, midnight UTC on 1 January 1970. It is the backbone of timekeeping in software because it is a single integer with no time zone ambiguity. Two things trip people up:
- Seconds versus milliseconds. Unix timestamps come in both; JavaScript uses milliseconds while most Unix tools use seconds. A value that looks 1,000 times too large or small is almost always the wrong unit.
- UTC is the reference, not your local time. A timestamp encodes an absolute instant in UTC; the local wall-clock time depends on the viewer's time zone and daylight saving offset.
- ISO 8601 with a Z means UTC. The trailing "Z" (Zulu) marks zero offset; an offset like +05:30 shifts the same instant to a local representation.
- The 2038 problem. Systems storing Unix time in a signed 32-bit integer overflow in January 2038; modern systems use 64-bit to avoid it.
Common date and time conversion pitfalls
- Confusing seconds and milliseconds. Feeding a millisecond value into a seconds-based parser places the date tens of thousands of years in the future; check the digit count.
- Ignoring the time zone. The same instant displays as different wall-clock times around the world; always note whether a value is UTC or local.
- Forgetting daylight saving. Local offsets shift by an hour twice a year, so a fixed offset can be wrong for half the calendar.
- Ambiguous DD/MM versus MM/DD. "03/04" is March 4 in the US and April 3 in much of the world; ISO 8601 (YYYY-MM-DD) removes the ambiguity.
- Assuming a parsed string keeps its original zone. Many parsers normalize to UTC, so the output may differ from the offset you typed even though it marks the same instant.
Related tools
Frequently asked questions
What is a Unix timestamp?
A Unix timestamp is the number of seconds since midnight UTC on 1 January 1970, the Unix epoch. It represents an exact instant as a single integer with no time zone ambiguity, which is why logs and programming languages use it. For example, 1779892200 is 28 May 2026 at 14:30 UTC.
What is the difference between Unix seconds and milliseconds?
Both count from the same 1970 epoch, but milliseconds are 1,000 times larger. Most Unix tools and databases use seconds (10 digits around now), while JavaScript's Date uses milliseconds (13 digits). A value that lands thousands of years off is almost always the wrong unit; divide or multiply by 1,000 to fix it.
What does the Z mean in an ISO 8601 timestamp?
The Z stands for Zulu time, meaning UTC with zero offset. So 2026-05-28T14:30:00Z is 14:30 UTC. A suffix like +05:30 instead of Z shifts the same instant to a local representation, here five and a half hours ahead of UTC. ISO 8601 is unambiguous because it always states the offset.
Why does my converted time differ from what I typed?
Because the parser normalizes to UTC. If you enter a local time, the tool converts it to the equivalent UTC instant and shows that, so the digits change even though the moment is identical. Daylight saving offsets can shift it by an hour depending on the date. The underlying instant is preserved; only the representation changes.
What is the year 2038 problem?
Systems that store Unix time in a signed 32-bit integer can only count up to 03:14:07 UTC on 19 January 2038, after which the value overflows and wraps to a negative number, misreading the date. Modern systems store timestamps in 64-bit integers, which pushes the limit billions of years out and avoids the issue.