{ "slug": "date-format-normalizer", "name": "gizza-ai/date-format-normalizer", "version": "0.1.0", "title": "Date Format Normalizer — rewrite every date in a text to one format — gizza.ai", "description": "Paste text with dates in mixed formats and get them all rewritten to ISO 8601 or any format you pick, with the day/month order settled from the text. Free and private.", "tags": [ "date format normalizer", "normalize dates in text", "convert dates to iso 8601", "bulk date format converter", "change date format online", "dd/mm vs mm/dd converter", "standardize date formats", "date cleaner" ], "category": "data", "urls": { "page": "https://gizza.ai/tools/date-format-normalizer/", "markdown": "https://gizza.ai/tools/date-format-normalizer/index.md", "descriptor": "https://gizza.ai/tools/date-format-normalizer/tool.json", "deep_link_example": "https://gizza.ai/tools/date-format-normalizer/?text=Order%204471%20was%20placed%2003%2F04%2F2024%20and%20shipped%2015%2F04%2F2024.%0AThe%20invoice%20is%20dated%2022%20April%202024%20and%20falls%20due%202024-05-06.%0ASupport%20ticket%20opened%20Friday%2C%203%20May%202024%20at%202%3A30%20PM.&output_format=iso&custom_format=%25d.%25m.%25Y&separator=dash&month_style=full&year_style=four&leading_zeros=true&input_order=auto&two_digit_year_pivot=68&keep_time=true&time_style=24h&output_timezone=source&detect_timestamps=true&output_mode=text" }, "cli": "gizza tool date-format-normalizer \"Order 4471 was placed 03/04/2024 and shipped 15/04/2024.\nThe invoice is dated 22 April 2024 and falls due 2024-05-06.\nSupport ticket opened Friday, 3 May 2024 at 2:30 PM.\"", "tool": { "description": "Find every date string in a block of text and rewrite them all into one format, leaving the surrounding words untouched. Paste the text into `text`. Detection runs per occurrence, so one paste can mix ISO 8601 (2024-01-05, 2024-01-05T14:30:00Z), slash/dot/dash numbers (01/05/2024, 5.1.2024, 5-1-24), year-first numbers (2024/01/05) and month names with optional weekday and ordinal (January 5, 2024; Jan. 5th, 2024; 5 Jan 2024; Friday, 5 January 2024 14:30 +0100); a clock time written beside a date travels with it, including \"at 2:30 PM\" and a trailing Z or +01:00. `output_format` picks iso (default), ymd, dmy, mdy, month_day_year, day_month_year, rfc2822, unix_seconds, unix_millis or custom (a strftime pattern in `custom_format`), shaped further by `separator`, `month_style`, `year_style`, `leading_zeros`, `keep_time` and `time_style`. The 03/04/2024 ambiguity is settled by `input_order`: at the default \"auto\" the whole text is read first and any date that can only be one thing (a field above 12) decides the reading for the rest, falling back to month-first when nothing settles it; \"day_first\" and \"month_first\" force it. `two_digit_year_pivot` decides the century for years like 24 or 70. `output_timezone` moves the dates that carry an explicit offset into UTC, an IANA zone or a fixed offset — zone-less dates are left alone. `detect_timestamps` (off by default) additionally reads bare 10- and 13-digit epoch numbers as dates. `output_mode` returns the rewritten text (default), just the normalized values one per line, or a report with line/column, original, result and an ambiguity flag. Strings that only look like dates (2024-02-30, 13/13/2024, version numbers) are never guessed at. No clock and no I/O — the same input always produces the same output. Up to 1000000 bytes per run.", "parameters": { "additionalProperties": false, "properties": { "custom_format": { "default": "", "description": "The strftime pattern used when output_format is \"custom\" — for example \"%d.%m.%Y\" (05.01.2024), \"%B %-d, %Y\" (January 5, 2024), \"%Y%m%d\" (20240105) or \"%Y-%m-%dT%H:%M:%S%z\". Useful fields: %Y four-digit year, %y two-digit year, %m month, %d day, %-m and %-d drop the leading zero, %B full month name, %b short month name, %A weekday, %H:%M:%S 24-hour clock, %I:%M %p 12-hour clock, %j day of the year, %z the UTC offset. Ignored unless output_format is \"custom\"; an invalid pattern is reported rather than silently half-rendered.", "type": "string" }, "detect_timestamps": { "default": false, "description": "Also treat bare 10-digit and 13-digit numbers as unix timestamps in seconds and milliseconds, so 1704465000 becomes 2024-01-05T14:30:00Z. Off by default on purpose: most long numbers in real text are order ids, phone numbers or account references, not dates. When on, only values between 1973 and 2100 are accepted, which filters out the obvious non-dates. Turn it on for log exports and API payloads where epoch values are genuinely mixed into the text.", "type": "boolean" }, "input_order": { "default": "auto", "description": "How to read a numeric date whose first two fields are both 12 or less — the 03/04/2024 problem, which is 3 April in most of the world and 4 March in the US. \"auto\" (default) reads the whole text first and lets the dates that can only be one thing decide for the rest: one 15/04/2024 in the paste settles it as day-first, one 04/15/2024 as month-first. With no such date, or with the text contradicting itself, it falls back to month-first and says so in the report output mode. \"day_first\" and \"month_first\" skip the inference and force the reading — use them when you know where the data came from. Dates that can only be read one way (a field above 12) always keep that reading.", "enum": [ "auto", "day_first", "month_first" ], "type": "string" }, "keep_time": { "default": true, "description": "Carry a clock time into the output when the source date had one — 2024-01-05T14:30:00Z stays a date and time. On by default. Turn it off to reduce everything to a bare date, which is what you want when the times are noise or when the values are going into a column that must hold dates only. Dates with no time are unaffected either way.", "type": "boolean" }, "leading_zeros": { "default": true, "description": "Pad single-digit days and months with a zero in the numeric formats: 05/01/2024 with it on (the default), 5/1/2024 with it off. Turn it off for the way people write dates by hand and for spreadsheet cells that should not be read as text. Month-name formats never pad the day (January 5, 2024, not January 05, 2024), and iso, rfc2822 and unix always pad.", "type": "boolean" }, "month_style": { "default": "full", "description": "How the month is spelled in the month_day_year and day_month_year formats. \"full\" (default) writes it out — January 5, 2024. \"short\" uses the three-letter abbreviation — Jan 5, 2024 — which is what fits in a narrow column or a chart axis. The numeric formats are unaffected.", "enum": [ "full", "short" ], "type": "string" }, "output_format": { "default": "iso", "description": "The one format every detected date is rewritten into. \"iso\" (default) is ISO 8601 — 2024-01-05, or 2024-01-05T14:30:00Z when a time came with it — and ignores the separator, year_style and time_style knobs because ISO fixes them. \"ymd\", \"dmy\" and \"mdy\" are numeric in that field order (2024-01-05, 05-01-2024, 01-05-2024) and honour separator, year_style and leading_zeros. \"month_day_year\" is January 5, 2024 and \"day_month_year\" is 5 January 2024, both following month_style. \"rfc2822\" is the email/HTTP date Fri, 5 Jan 2024 14:30:00 +0000. \"unix_seconds\" (1704412800) and \"unix_millis\" are bare numbers. \"custom\" renders the chrono/strftime pattern you pass in custom_format.", "enum": [ "iso", "ymd", "dmy", "mdy", "month_day_year", "day_month_year", "rfc2822", "unix_seconds", "unix_millis", "custom" ], "type": "string" }, "output_mode": { "default": "text", "description": "What comes back. \"text\" (default) is the original text with every date rewritten in place and nothing else changed — paste it straight back where it came from. \"list\" is just the normalized dates, one per line, in the order they appear, ready for a spreadsheet column. \"report\" is an audit trail: a \"#\" header with how many dates were found, the mix of source forms detected and which day/month order was chosen and why, then one tab-separated line per date giving its line and column, the original string, the rewritten value, and whether it was ambiguous.", "enum": [ "text", "list", "report" ], "type": "string" }, "output_timezone": { "default": "source", "description": "Where to place the dates that carry an explicit UTC offset — an ISO stamp ending in Z or +01:00, an RFC 2822 date, a detected epoch value. \"source\" (default) leaves each one on the offset it was written with. Pass \"UTC\", an IANA zone name such as \"Europe/Berlin\", \"America/New_York\" or \"Asia/Tokyo\" (daylight saving applied per date from the bundled IANA database), or a fixed offset such as \"+02:00\", \"-0700\" or \"UTC+5:30\" to move them, which can shift the calendar day itself. Dates written without any zone are left exactly where they are — there is nothing to convert them from.", "type": "string" }, "separator": { "default": "dash", "description": "The character between the numeric fields of the ymd, dmy and mdy formats. \"dash\" (default) gives 05-01-2024, \"slash\" 05/01/2024, \"dot\" 05.01.2024 (the usual European written form), \"space\" 05 01 2024, and \"none\" 05012024 — which with ymd and leading_zeros is the 20240105 stamp filenames and folder names sort correctly by. The iso, month-name, rfc2822, unix and custom formats set their own punctuation and ignore this.", "enum": [ "dash", "slash", "dot", "none", "space" ], "type": "string" }, "text": { "description": "The text whose dates you want rewritten — prose, notes, a pasted table, an exported record. Every date is detected where it sits and replaced in place, so the words around it are untouched. One paste can mix formats: ISO 8601 (2024-01-05, 2024-01-05T14:30:00Z), slash/dot/dash numbers (01/05/2024, 5.1.2024, 5-1-24), year-first numbers (2024/01/05), and month names with or without a weekday and an ordinal (January 5, 2024; Jan. 5th, 2024; 5 Jan 2024; Friday, 5 January 2024 14:30 +0100). A clock time written next to a date is picked up with it, including \"at 2:30 PM\" and a trailing Z or +01:00. Strings that only look like dates (2024-02-30, 13/13/2024, a version number) are left exactly as written. Up to 1000000 bytes per run.", "type": "string" }, "time_style": { "default": "24h", "description": "The clock the time is written on in the ymd, dmy, mdy and month-name formats. \"24h\" (default) gives 14:30; \"12h\" gives 2:30 PM. Seconds are shown only when the source had them. ISO 8601 and RFC 2822 are always 24-hour by definition, and the unix formats have no clock at all, so this does not touch them.", "enum": [ "24h", "12h" ], "type": "string" }, "two_digit_year_pivot": { "default": 68, "description": "Which century a two-digit year belongs to. A year at or below this number becomes 20xx and anything above becomes 19xx, so at the default 68 the year 24 is 2024 and 70 is 1970 (the POSIX convention). Raise it to 99 to force every two-digit year into the 2000s, or lower it when the data is full of twentieth-century birthdays. Only affects dates written with a two-digit year, such as 5-1-24.", "maximum": 99, "minimum": 0, "type": "integer" }, "year_style": { "default": "four", "description": "Whether the year is written in full or shortened. \"four\" (default) writes 2024. \"two\" writes 24, matching the compact 05/01/24 style still used on forms and labels. It applies to the ymd, dmy, mdy and month-name formats; iso, rfc2822, unix and custom always write the year their own way. Round-tripping through \"two\" loses the century, so keep \"four\" for anything a machine will read back.", "enum": [ "four", "two" ], "type": "string" } }, "required": [ "text" ], "type": "object" } } }