Paste any ISO 8601 or RFC 3339 date/time string and get it reformatted every way you might need it. Useful for debugging API responses, converting between UTC and local time, pulling out the Unix timestamp, and checking what day of the week a specific date falls on.
What the tool accepts
Any valid ISO 8601 date/time string:
- Date only:
2026-04-15 - Date with time:
2026-04-15T12:34:56 - Date with time and milliseconds:
2026-04-15T12:34:56.789 - With UTC Z marker:
2026-04-15T12:34:56.789Z - With offset:
2026-04-15T12:34:56+02:00or2026-04-15T12:34:56-05:00
The parser uses the browser’s native new Date(string), which handles all the common ISO forms. Strings without an explicit timezone are interpreted as local time (which is the browser default); strings with Z or an offset are interpreted in UTC. The tool then emits UTC and local-time views side by side so you can see both.
What the tool outputs
For a valid parse, the result shows:
- ISO 8601 UTC — the canonical form with Z suffix
- ISO 8601 local — the same instant in your browser’s timezone
- Human readable (UTC) — “Wednesday, 15 April 2026 at 12:34:56 UTC”
- Human readable (local) — same in your timezone
- Unix timestamp (seconds) — integer seconds since the 1970 epoch
- Unix timestamp (milliseconds) — integer ms (JS Date’s native value)
- Date only — YYYY-MM-DD, stripped of time
- Time only (UTC) — HH:MM:SS, stripped of date
- Weekday (UTC) — day-of-week name
- Day of year — 1–366 integer
- ISO week date — YYYY-Www-D alternative notation
Each row has a copy button so you can grab the representation you need without selecting text by hand.
Example: debugging a Slack webhook timestamp
Slack webhook events arrive with a ts field like "ts": "1776263696.123456" (seconds as a float). Convert it by pasting the integer part into a date input, or multiply by 1000 and use JavaScript’s new Date(number). The reverse — taking a human-readable date and producing a Unix timestamp for a test fixture — is what this tool is for.
Example: cross-timezone coordination
A GitHub Actions log shows a job ran at 2026-04-15T16:34:56Z. You’re in Eastern Time (UTC−4 during EDT) and want to know when that was for you locally. Paste the string, read off the “Human readable (local)” line: “Wednesday, 15 April 2026 at 12:34:56 (-04:00)”. Done — the job ran at 12:34 PM your time.
Example: ISO week date conversion
A European payroll system generates files labeled with ISO week dates: “week 16 of 2026, Wednesday”. You need to know the calendar date to reference the file. Parse any date in that week, read off the ISO week date value, and cross-check: 2026-04-15 is “2026-W16-3” (week 16, day 3, i.e. Wednesday). The tool doesn’t parse ISO week dates as input (those need a dedicated parser) but it displays them for every valid calendar-date input.
UTC vs local
The tool shows both UTC and local time because they’re almost always both useful at the same time. API responses are usually in UTC; human-readable displays are usually local. If you’re debugging something that involves both ends of the chain — “my server logged this at 16:34 UTC, what does that look like in my dev tools?” — the side-by-side view is more useful than having to run two separate conversions.
Your local offset comes from the browser, which reads it from the operating system. It’s automatically correct for daylight saving if your OS is — the tool shows whatever offset is active at the moment you load the page.
What this tool does not do
It doesn’t parse non-ISO date formats — US-style slashes, European-style slashes, month names, relative dates (“yesterday”). For those, use the browser’s native new Date() directly or a dedicated date-parsing library like date-fns.
It doesn’t handle ISO week date input — the input is always a calendar date. If you have a string like “2026-W16-3” you’ll need to convert it to a calendar date first.
It doesn’t account for leap seconds. Unix timestamps traditionally don’t either — the one-second discontinuities from leap seconds are smeared or ignored by almost all practical systems.
It doesn’t support timezone names (like “America/New_York”) in input or output. The tool only works with numeric offsets. For zone-aware conversion between IANA zone names, the timezone converter is the right tool. For Unix seconds ↔ human date instead of ISO strings, the Unix timestamp converter is the companion.