A logistics warehouse merges scan times from three partners. One file writes month-day-year text, another writes day-month-year text, and the third writes year-month-day text. Sorted as raw strings, March scans land in the wrong place. What must happen before the scans are ordered on a calendar?

Date text is not a timestamp until a format interprets it. Month-day-year, day-month-year, and year-month-day assign the same digits to different calendar parts, so a string sort follows character order rather than time. Each feed has to be parsed with its own format into one timestamp type before a calendar sort or a duration is valid. Alphabetical order does not recover calendar order once month-first and day-first strings share a column, which is why March lands in the wrong place. Stripping separators and comparing digits still leaves the month and the day in whatever positions the partner used, so the numbers are not yet on one calendar. Subtracting the raw strings is not time arithmetic and breaks as soon as the formats differ. Exam caveat: an ambiguous string such as 04-05-2026 still needs a declared format, because parsing cannot invent which partner uses month-first. Operational check: parse a known March scan from each partner file and confirm all three timestamps fall in March before the merged log is sorted.