Date Formatter

Format a date in dozens of common patterns at once: ISO 8601, RFC 2822, Unix timestamp, US/EU, and more.

Quick Presets:

Select Date

Time (HH:mm)

Search Formats

Showing 25 of 25 formats

Format Name	Formatted Output	Copy
ISO 8601 Date	2026-06-16
ISO 8601 Date+Time (UTC)	2026-06-16T12:00:00Z
ISO 8601 Local	2026-06-16T12:00:00
RFC 2822	Tue, 16 Jun 2026 12:00:00 +0000
Unix Timestamp (seconds)	1781611200
Unix Timestamp (milliseconds)	1781611200000
US Date (M/D/YYYY)	6/16/2026
US Date (MM/DD/YYYY)	06/16/2026
EU Date (D/M/YYYY)	16/6/2026
EU Date (DD/MM/YYYY)	16/06/2026
ISO compact (YYYYMMDD)	20260616
Long form	June 16, 2026
Long form with day	Tuesday, June 16, 2026
Short form	Jun 16, 2026
Year-Month	2026-06
12-hour time	12:00 PM
24-hour time	12:00
Day of year	167
Week number (approx)	24
Month name	June
Day name	Tuesday
Slashes (M/D/YY)	6/16/26
Dashes (DD-MM-YYYY)	16-06-2026
Dots (DD.MM.YYYY)	16.06.2026
SQL DateTime	2026-06-16 12:00:00

Relative: Selected Date

Time: 12:00Leap Year: NoDay of Year: 167

Date Formatter — All Common Formats

Different systems expect dates in different formats: APIs often use ISO 8601, email headers use RFC 2822, databases use SQL DateTime, and Unix timestamps (seconds since epoch) are common in logs and APIs. This tool shows a single date in all common formats simultaneously, making it easy to copy exactly what you need.

Built and maintained by Meet Shah · Last updated 31 July 2026

What this tool is used for

Seeing one date in every common format at once to find the one a system wants.
Producing an ISO 8601 string for an API that requires it.
Converting a date into an RFC form for a header or an email.
Checking how a date renders in a long-form locale style.
Getting a Unix timestamp alongside a human-readable form.

Frequently Asked Questions

Why is ISO 8601 the right storage format?: Because `2026-08-15T12:30:00Z` sorts lexicographically in chronological order and states its offset unambiguously. `08/15/26` means two different dates on opposite sides of the Atlantic, which is why the ambiguous formats belong only in display.
What is the difference between formatting patterns?: There are several incompatible conventions. `YYYY` means calendar year in most libraries and `yyyy` is the ICU spelling, while `YYYY` in ICU is week-based year — which produces a date a year off for a few days each January. It is a genuinely notorious bug.
How should localised dates be produced?: With `Intl.DateTimeFormat`, not a hand-written pattern. It knows each locale's field order, month names, era handling and non-Gregorian calendars, none of which a format string can encode — and it is built into every runtime rather than being a dependency.
Why does my date shift by a day?: Almost always a timezone boundary. A date-only value parsed as UTC midnight and displayed in a negative-offset zone renders as the previous day. Date-only values should be handled as dates rather than as instants, which is what `Temporal.PlainDate` exists for.
What is the safest way to parse a date string?: Know the format and parse it explicitly. `new Date(string)` is specified only for ISO 8601 and falls back to implementation-defined behaviour for everything else, so the same string can parse differently across engines and versions.

Common errors and gotchas

Omitting the time zone, which makes a timestamp ambiguous the moment it is shared.
Using a day-month order for an audience that reads month-day, or the reverse.
Assuming a two-digit year is unambiguous.
Confusing the RFC forms, where email and HTTP headers have historically differed.
Treating a formatted string as sortable, which only the ISO form reliably is.