Date Format Cheat Sheet
A side-by-side comparison of every common date and time format — with examples, format string patterns for JavaScript, Python, Java, C#, and SQL, and notes on where you'll encounter each one.
Why Date Formats Are a Mess
There is no single "correct" way to write a date. The United States uses month-first (06/29/2024). Most of Europe uses day-first (29.06.2024 or 29/06/2024). Japan and China use year-first (2024年6月29日). Databases use ISO format (2024-06-29). Unix systems use epoch seconds (1719619200). Email headers use RFC 2822 format (Sat, 29 Jun 2024 14:30:00 +0000).
Every format serves a purpose, and every system has opinions about which one to use. This cheat sheet puts them all in one place so you can quickly identify any format you encounter and find the right pattern to parse or generate it.
Date-Only Formats
| Format | Example | Used By |
|---|---|---|
YYYY-MM-DD | 2024-06-29 | ISO 8601, SQL DATE, HTML <input type="date"> |
MM/DD/YYYY | 06/29/2024 | United States, Philippines |
M/D/YYYY | 6/29/2024 | US informal, Excel (US locale) |
DD/MM/YYYY | 29/06/2024 | UK, Australia, most of Europe, India |
DD.MM.YYYY | 29.06.2024 | Germany, Russia, much of continental Europe |
YYYY.MM.DD | 2024.06.29 | China, Korea, Hungary |
MMM DD, YYYY | Jun 29, 2024 | US formal/editorial, AP style |
DD MMM YYYY | 29 Jun 2024 | UK formal, military, RFC 2822 (email) |
MMMM DD, YYYY | June 29, 2024 | US long-form, legal documents |
Date + Time Formats
| Format | Example | Used By |
|---|---|---|
YYYY-MM-DDTHH:mm:ssZ | 2024-06-29T14:30:00Z | ISO 8601, REST APIs, JSON |
YYYY-MM-DDTHH:mm:ss.SSSZ | 2024-06-29T14:30:00.000Z | JavaScript toISOString(), Java |
YYYY-MM-DDTHH:mm:ss±HH:mm | 2024-06-29T14:30:00+05:30 | ISO 8601 with offset, RFC 3339 |
YYYY-MM-DD HH:mm:ss | 2024-06-29 14:30:00 | SQL DATETIME, Python str(), database exports |
MM/DD/YYYY HH:mm:ss | 06/29/2024 14:30:00 | US 24-hour, log files |
M/D/YYYY h:mm:ss A | 6/29/2024 2:30:00 PM | US 12-hour, Excel (US locale) |
DD.MM.YYYY, HH:mm:ss | 29.06.2024, 14:30:00 | German/European with time |
Unix (seconds) | 1719619200 | Unix/Linux, databases, APIs |
Unix (milliseconds) | 1719619200000 | JavaScript, Java, analytics platforms |
MMM DD, YYYY, h:mm:ss A | Jun 29, 2024, 2:30:00 PM | US verbose, Salesforce, CRM exports |
MMMM DD, YYYY at h:mm A | June 29, 2024 at 2:30 PM | Apple/iOS, verbose UI display |
Format String Patterns by Language
Different languages use different tokens in their format strings. Here's a Rosetta Stone for the most common date formatting patterns:
Date: June 29, 2024
| Component | JavaScript (Intl/Luxon) | Python (strftime) | Java (DateTimeFormatter) | C# (.NET) |
|---|---|---|---|---|
| 4-digit year | yyyy | %Y | yyyy | yyyy |
| 2-digit year | yy | %y | yy | yy |
| Month (01–12) | MM | %m | MM | MM |
| Month (1–12) | M | %-m | M | M |
| Month name (Jun) | MMM | %b | MMM | MMM |
| Month name (June) | MMMM | %B | MMMM | MMMM |
| Day (01–31) | dd | %d | dd | dd |
| Day (1–31) | d | %-d | d | d |
| Hour 24h (00–23) | HH | %H | HH | HH |
| Hour 12h (01–12) | hh | %I | hh | hh |
| Minute (00–59) | mm | %M | mm | mm |
| Second (00–59) | ss | %S | ss | ss |
| Milliseconds | SSS | %f (microseconds) | SSS | fff |
| AM/PM | a | %p | a | tt |
| Timezone offset | ZZ | %z | XXX | zzz |
Example: Format "June 29, 2024 2:30 PM"
// JavaScript (Luxon)
DateTime.now().toFormat('MMMM dd, yyyy h:mm a')
# Python
datetime.now().strftime('%B %d, %Y %-I:%M %p')
// Java
DateTimeFormatter.ofPattern("MMMM dd, yyyy h:mm a")
// C#
DateTime.Now.ToString("MMMM dd, yyyy h:mm tt")Example: Format "2024-06-29T14:30:00Z" (ISO 8601)
// JavaScript
new Date().toISOString()
# Python
from datetime import datetime, timezone
datetime.now(timezone.utc).isoformat()
// Java
Instant.now().toString()
// C#
DateTime.UtcNow.ToString("o")SQL Date Functions
| Task | MySQL | PostgreSQL | SQLite |
|---|---|---|---|
| Current timestamp | NOW() | NOW() | datetime('now') |
| Format date | DATE_FORMAT(d, '%Y-%m-%d') | TO_CHAR(d, 'YYYY-MM-DD') | strftime('%Y-%m-%d', d) |
| Parse string | STR_TO_DATE(s, '%m/%d/%Y') | TO_DATE(s, 'MM/DD/YYYY') | (use strftime) |
| Unix → datetime | FROM_UNIXTIME(ts) | TO_TIMESTAMP(ts) | datetime(ts, 'unixepoch') |
| Datetime → Unix | UNIX_TIMESTAMP(d) | EXTRACT(EPOCH FROM d) | strftime('%s', d) |
The Ambiguous Six: Dates That Parse Differently by Locale
These date strings are valid in multiple formats but mean different things depending on interpretation. They're the most common source of date bugs in international systems:
| String | US Interpretation (M/D/Y) | European Interpretation (D/M/Y) |
|---|---|---|
01/02/2024 | January 2, 2024 | February 1, 2024 |
03/04/2024 | March 4, 2024 | April 3, 2024 |
05/06/2024 | May 6, 2024 | June 5, 2024 |
07/08/2024 | July 8, 2024 | August 7, 2024 |
09/10/2024 | September 10, 2024 | October 9, 2024 |
11/12/2024 | November 12, 2024 | December 11, 2024 |
Any date where both the day and month are 12 or below is inherently ambiguous in slash-separated formats. The only reliable way to avoid this is to use ISO 8601 (2024-06-29), include a month name (Jun 29, 2024), or know the source system's locale with certainty.
How Auto-Detection Works
When you paste a date into a converter that auto-detects the format, it uses pattern matching and heuristics:
Unambiguous signals: The letter T between date and time components signals ISO 8601. A trailing Z or UTC offset (+05:30) confirms it. A 10-digit number is almost certainly a Unix timestamp in seconds. A 13-digit number is milliseconds. Month names (Jun, June) eliminate month/day ambiguity.
Ambiguous cases: When faced with 06/29/2024, the detector knows the day is 29 (which exceeds 12), so the first component must be the month — this is M/D/Y format. But 06/07/2024 could be either M/D/Y or D/M/Y. Most auto-detectors default to the locale of the user or the system, or ask the user to confirm.
Separator clues: Dashes (-) with year-first suggest ISO 8601. Dots (.) suggest European format. Slashes (/) suggest US or UK format depending on the order. Commas after a month name suggest US verbose format.
Best Practices
Store dates as ISO 8601 or Unix timestamps. Both are unambiguous, sortable, and universally parseable. Use ISO 8601 when human readability in the database matters. Use Unix timestamps when you want the simplest possible storage and comparison.
Always include timezone information. A datetime without a timezone is an accident waiting to happen. Use Z for UTC, or include the offset. If storing in a database, use TIMESTAMP WITH TIME ZONE (PostgreSQL) or always store in UTC.
Format for display at the last moment. Store and transmit dates in a canonical format (ISO 8601 or timestamps). Convert to the user's local format only at the point of display.
Validate on input. If your system accepts dates from users, validate that the input matches the expected format. Don't rely on "flexible parsing" that silently interprets 02/03/2024 as March 2nd when the user meant February 3rd.
Related Guides
For a deep dive on Unix timestamps specifically, see What Is a Unix Timestamp?. For the full ISO 8601 standard explained, see ISO 8601 Explained. For timezone abbreviations and their offsets, see the Timezone Abbreviations Reference. To apply all of this to real data, see How to Convert Dates in CSV Files. For the email date format (RFC 2822), see RFC 2822: The Email Standard.
Try It Yourself
Convert any date or timestamp instantly — free, no sign-up required.
Open the Converter