The CONVERT(varchar, date_value, style_code) function in SQL Server is the standard way to convert a date format in SQL, where style_code is a predefined integer such as 101 for US (mm/dd/yyyy), 103 for British/European (dd/mm/yyyy), or 120 for ISO 8601 (yyyy-mm-dd). MySQL uses DATE_FORMAT(date, 'pattern') with literal pattern strings like '%Y-%m-%d', while PostgreSQL uses TO_CHAR(date, 'pattern') with patterns like 'YYYY-MM-DD'. All three dialects accept a literal ISO date when inserted into a DATE column, so converting a date to 'YYYY-MM-DD' before sending it to the database is the most portable approach. The style codes and pattern strings are officially documented per vendor and let you reshape the same date into any common format without leaving SQL.
Because style codes vary by database engine, many developers prefer to format the date once on the application side, paste it into a parameter, and let SQL store it. That is exactly where a general-purpose date format converter saves time: pick a date, copy the ISO form, drop it into the query, and skip the trial-and-error of remembering style numbers.
SQL Date Format Conversion: What It Really Means
"Converting date format in SQL" covers three related jobs. The first is reformatting a date value as a string for display, the second is converting between SQL data types such as DATETIME, DATE, and TIMESTAMP, and the third is producing a date string that fits a specific column definition or API payload. Each of those jobs uses a different function in T-SQL, MySQL, and PostgreSQL, but they all share the same goal of getting the date into a shape the rest of the system can read.
Format conversion does not change the underlying point in time. Converting '2026-07-06 14:30:00' to '2026-07-06' only strips the time portion; the day stays July 6. Reformatting '2026-07-06' to '07/06/2026' or '06/07/2026' is purely cosmetic and depends entirely on the audience: US readers expect month first, most of the world expects day first, and ISO 8601 avoids the confusion by always writing year first.
The Main SQL Functions for Date Conversion
SQL Server, MySQL, and PostgreSQL each ship a small set of functions for date conversion. Picking the right one matters because CAST follows the ANSI standard while CONVERT is SQL Server specific and richer in style options, and FORMAT-style functions trade speed for readability.
- CAST(value AS type) — ANSI standard; works in every engine for changing DATETIME to DATE or DATE to VARCHAR.
- CONVERT(type, value [, style]) — SQL Server and Synapse; the third argument picks a numeric style code.
- FORMAT(value, format [, culture]) — SQL Server 2012+; uses .NET-style patterns and is convenient but slower than CONVERT.
- DATE_FORMAT(value, pattern) — MySQL only; pattern strings use %-codes like '%Y-%m-%d'.
- TO_CHAR(value, pattern) — PostgreSQL and Oracle; pattern strings use 'YYYY-MM-DD' style.
- STR_TO_DATE(string, pattern) — MySQL; the reverse of DATE_FORMAT, used when parsing text into a date.
For most date format tasks, CAST and CONVERT cover the change between DATE and DATETIME, while the FORMAT-family functions handle the cosmetic reformatting. If you need to drop the time portion, CONVERT(DATE, your_column) in SQL Server or your_column::date in PostgreSQL is the shortest path. MySQL handles the same task with CAST(your_column AS DATE) or DATE(your_column).
SQL Server CONVERT Style Codes You Will Use Most
SQL Server's style codes are officially documented integers that map to fixed output formats. Style 120 and 121 are the ISO 8601 forms and are the only ones guaranteed to sort correctly as plain text. The table below covers the codes that show up in real-world queries.
| Style | Output format | Example (for 6 July 2026) | Region / use |
|---|---|---|---|
| 101 | mm/dd/yyyy | 07/06/2026 | United States |
| 103 | dd/mm/yyyy | 06/07/2026 | Britain / France / most of Europe |
| 104 | dd.mm.yyyy | 06.07.2026 | Germany |
| 105 | dd-mm-yyyy | 06-07-2026 | Italy |
| 110 | mm-dd-yyyy | 07-06-2026 | USA, hyphen form |
| 111 | yyyy/mm/dd | 2026/07/06 | Japan / ISO-ish |
| 112 | yyyymmdd | 20260706 | ISO compact |
| 120 | yyyy-mm-dd hh:mi:ss | 2026-07-06 14:30:00 | ODBC canonical |
| 121 | yyyy-mm-dd hh:mi:ss.mmm | 2026-07-06 14:30:00.000 | ODBC with milliseconds |
| 126 | yyyy-mm-ddThh:mi:ss.mmm | 2026-07-06T14:30:00.000 | ISO 8601 string |
| 127 | yyyy-mm-ddThh:mi:ss.mmmZ | 2026-07-06T14:30:00.000Z | ISO 8601 with time zone |
For pure date output (no time), combine CONVERT with a cast to a fixed-length character string: SELECT CONVERT(CHAR(10), GETDATE(), 120) returns the ISO date '2026-07-06' without the time portion, which is the form most queries actually need. In MySQL the equivalent is DATE_FORMAT(NOW(), '%Y-%m-%d'), and in PostgreSQL it is TO_CHAR(CURRENT_DATE, 'YYYY-MM-DD').
How to Convert Date Format in SQL Using the Date Format Converter
When you are about to hand a date to a SQL query, you usually want the ISO form pre-built and copy-pasteable. The Date Format Converter produces every common format side by side, each on its own line with a copy button, so you can grab the exact string SQL expects.
- Pick a date in the date field; it defaults to today.
- Read every format instantly below: ISO, US, European, long, weekday, ordinal, words, and Unix.
- Click Copy on the line that matches your SQL style code, such as ISO 8601 (2026-07-06) for style 120, US (07/06/2026) for style 101, or European (06/07/2026) for style 103.
- Paste the copied value into your SQL parameter, WHERE clause, or INSERT statement.
The ISO 8601 line is the one you will use most often because style codes 120, 121, 126, and 127 all share the year-first, hyphen-separated shape. The Unix timestamp line is useful when you need an epoch value for BIGINT columns or for comparing against a UNIX_TIMESTAMP() result in MySQL. Every output runs in your browser, so the date you enter never leaves your device.
SQL Examples: Stripping Time, Inserting ISO Dates, and Filtering by Range
Three concrete use cases come up in almost every SQL codebase.
1. DATETIME to DATE. To remove the time portion without changing the day, cast to DATE. SQL Server: SELECT CAST(GETDATE() AS DATE); PostgreSQL: SELECT CURRENT_TIMESTAMP::date; MySQL: SELECT CAST(NOW() AS DATE); All three return the calendar day only.
2. Format for display. To render the day in US form for a report: SQL Server style 101 — SELECT CONVERT(VARCHAR(10), GETDATE(), 101); returns '07/06/2026'. For European form, swap to style 103 and the same date renders as '06/07/2026'.
3. Insert an ISO date string. When the source is text, a literal ISO date is accepted by every engine without parsing: INSERT INTO orders (order_date) VALUES ('2026-07-06'); The Date Format Converter's ISO 8601 line gives you that exact string, ready to drop into the query.
If you need to filter a TIMESTAMP column by an entire calendar day, the safe pattern is a half-open range rather than equality: WHERE ts >= '2026-07-06' AND ts < '2026-07-07'. The equality form WHERE ts = '2026-07-06' only matches rows whose timestamp happens to fall on midnight of that day, which is rarely what you want.
SQL Date Conversion Best Practices
Stick to ISO 8601 in WHERE clauses, INSERT statements, and parameter binding so the same code runs unchanged across SQL Server, MySQL, and PostgreSQL. ISO 8601 also sorts correctly as text, which matters when dates appear in filenames or log lines.
Use CAST for the simple type change between DATE and DATETIME because it is portable, and reserve CONVERT for style-coded formatting that CAST cannot express. In MySQL and PostgreSQL, prefer DATE_FORMAT and TO_CHAR for display and keep the underlying column as a native DATE or TIMESTAMP, which avoids surprise string comparisons and lets the engine use any index on the column.
For date arithmetic that needs to roll across months and leap years, leave the work to the engine with DATEADD, DATE_ADD, or INTERVAL rather than adding 30 or 31 days in application code. When you need to add or subtract days from a date before running the SQL, the Date Add Subtract Calculator gives you a verified result to paste into your query without manual day counting.
If you only need the weekday for a column header, pulling it with DATENAME(WEEKDAY, your_column) in SQL Server or TO_CHAR(date, 'Day') in PostgreSQL is faster than reformatting the whole date. For more involved scenarios like working out an age from a birth date, an age calculator returns a clean value that is easier to inject than a hand-built expression.
Finally, be explicit about time zones. Style code 127 produces an ISO 8601 string with the Z suffix that marks UTC; style code 126 omits the zone. If your column stores UTC but your application lives in another zone, convert at the boundary with AT TIME ZONE in PostgreSQL or SYSDATETIMEOFFSET() in SQL Server rather than trusting the driver's default. Mirroring the UTC-midnight rule used for Unix timestamps, anchor every stored date to a known offset so reports never drift by a day across daylight-saving changes.