Start with the booking consequence
A date error can place a traveller on the wrong departure even when the spreadsheet looks neat. The difficult cases are often ordinary numeric strings such as 04/11/2026. Depending on the source convention, that can mean 4 November or 11 April. A plausible-looking date is therefore not enough evidence to approve the import.
Choose one booking source and one working list for the first review. Identify where the date is used: supplier reconciliation, a departure manifest, an agency itinerary or a follow-up reminder. Confirm who relies on that value and what record establishes the actual booked date.
Keep the task focused on preserving meaning. The goal is not to make every date cell share a preferred appearance as quickly as possible. It is to ensure that the date carried from the booking source still refers to the correct service day when the team uses the list.
Separate the source, the interpreted value and the display
Use three concepts in the working process. The source is the date as received from the booking system or supplier. The interpreted value is the date the spreadsheet will use for sorting or other operations. The display is how that value is presented to a reader.
Keep the original source available while checking the interpretation. If the team replaces every imported string with a formatted date immediately, it may lose the evidence needed to understand a reversal. A preserved source column or original export makes a later comparison possible.
The display should then help a colleague read the approved value. It cannot establish what the supplier intended. A date converted incorrectly can be displayed in an elegant long format and remain the wrong booking date.
Confirm the source convention
Check the supplier's export documentation, an explicit field definition or the booking record. Ask the supplier when the convention is unclear. Do not choose day-first or month-first simply because most colleagues use that style locally.
Look for an example that distinguishes the two conventions, such as a day value greater than twelve, but do not treat one example as proof that every row in a combined file follows the same rule. A manually assembled list may contain dates from several sources.
Record the confirmed convention beside the import process. Include whether the field contains only a date or a date and time. If the source supplies separate year, month and day fields, preserve those components rather than converting them into an ambiguous string before importing them.
Check the spreadsheet's locale deliberately
Google's spreadsheet-settings guidance explains that locale and time-zone changes apply to the whole spreadsheet and affect default date, number and currency formatting. Colleagues see those changes regardless of their own location. The locale is therefore a shared document setting, not merely a personal preference.
Review the setting before importing or converting data. On the desktop interface, Google places it in the spreadsheet's File settings under General. Agree the choice with the people who maintain the sheet, especially if other columns contain numbers or currencies.
Do not change the live working sheet's locale repeatedly while experimenting with a date column. Use a controlled copy or preparation area to understand the effect. A change intended to improve one imported field can alter how other data is displayed to the team.
Preserve raw text during preparation
Keep a preparation copy of the original export and a clear connection between each row and its booking reference. Use a dedicated source-date column whose purpose is to preserve what was received. Avoid manual retyping as the first step, because it adds another opportunity to change the value.
Review the current import options in the actual Sheets workflow and choose them deliberately. The key requirement is that the team can compare the original text with the interpreted result. If an automated import has already converted the data, return to the original export before assuming a display change can recover the intended date.
Preserve booking references as identifiers as well. An imported code that resembles a date is not necessarily a date field. Keep the source's field meaning clear so that the date-cleaning task does not silently change unrelated identifiers or remove useful leading characters.
Use DATEVALUE only when the format is understood
Google documents DATEVALUE as a function that converts a recognised date string into a date value. Its help notes that understood formats can depend on regional and language settings, and that some formats are not understood. It is a conversion tool, not evidence of the supplier's intended convention.
Test a representative source value in the preparation area and compare the resulting date with the confirmed booking record. If the function returns an error, investigate the input rather than hiding the error with a blank result. If it returns a valid date, still check that the day and month mean what the supplier intended.
Avoid applying a conversion to the whole column merely because the first row worked. Include ambiguous values, values with a day above twelve and any different source format found in the file. The test should represent the real variation the import process needs to handle.
Build a date from verified components when appropriate
Where the source provides separate numeric year, month and day fields, Google's DATE function can construct a date from those components. For example, DATE(2026,11,4) represents 4 November 2026 in a sheet using the applicable function syntax. The example is an illustration of component order, not a booking instruction.
Validate the components before using the result operationally. Google's DATE documentation explains that out-of-range month or day inputs can roll into another date rather than necessarily producing an error. A calculated date is therefore not proof that the original components were valid.
If the source is a combined text string, do not split it into components until its structure has been confirmed. Extracting the first number as a day is only correct when the source actually uses that convention. Keep the rule documented so that the next export can be reviewed against the same evidence.
Choose a display that makes reversals easier to notice
After the interpreted value has been checked, apply a consistent working display. A written month can help a human reader distinguish 4 November from 11 April. A documented year-month-day format can also be useful for exchanges with systems that expect it.
Google's formatting guidance provides custom date and time controls through Format and Number. Use those controls to display the approved values consistently. Check the result with the people who use the departure list, rather than selecting a format only because it is familiar to the person preparing the sheet.
Keep machine exchange requirements separate from guest communication. A system may need a particular numeric format, while a client message benefits from a clearly written month and local context. Use the format required by each purpose without changing the underlying booked date.
Review an illustrative cooking-class import
Imagine an agency receiving a cooking-class booking export with the source text 04/11/2026. The supplier confirms that its export uses day, month and year. The booking record also shows a class on 4 November. The preparation sheet should preserve the original string and produce a reviewed working date for that day.
If the imported value instead appears as 11 April after formatting with a written month, the problem has become visible. Changing the display back to 04/11/2026 would conceal the issue rather than resolve it. Return to the conversion rule and confirm the interpreted date against the source.
After correcting the preparation process, check the affected bookings and identify which working lists or messages used the earlier value. The scope of the correction comes from the actual import and downstream use. Do not assume that every historic file is affected, or that fixing one visible cell updates every copy already sent to the team.
Keep dates and timestamps distinct
A departure date and a timestamp can require different handling. A timestamp may describe when a booking was created, when a payment record changed or when a service starts in a particular place. Those meanings should not be collapsed into a single date column without a reason.
Confirm which field drives the operational list. A booking-created date does not identify the tour's service day. A timestamp exported in a different time-zone context may also need a documented interpretation before the team derives a local date from it.
When time zones matter, coordinate the date review with the calendar or system owner. Do not let a formatting task quietly become an undocumented conversion between time zones. Preserve the original field and the rule used to create the value the team will actually use.
Test the output in the way it will be used
After checking representative values, test a small operational task on the preparation copy. Sort the reviewed date column and confirm that the resulting order matches the intended chronology. Check that the whole booking row remains together and that the reference still identifies the same case.
Review a few departure selections against the source records. Include dates that would reveal a day-and-month reversal and any row that required manual clarification. A tidy column with no visible errors is not the same as a verified departure list.
Have a second person inspect the source convention and the result when the import will drive important guest arrangements. Give them the expected dates and evidence, not just a request to check whether the sheet looks reasonable. Their review should address the meaning of the data.
Release the list with a clear status
Name the person who approves the reviewed import and record the source file, conversion rule, locale and review date. Mark unresolved rows clearly and keep them out of a list presented as confirmed until the responsible person resolves the meaning.
Do not overwrite the only original file when publishing the cleaned working list. Preserve the connection between the received data and the approved output so that a future query can be traced without reconstructing the import from memory.
Tell users which column is the operational date and which column preserves the source. A preparation sheet can become confusing if colleagues choose whichever field looks familiar. The release note should make the approved use clear while keeping the supporting evidence available to the people who maintain the process.
Reuse the checked process, then check for source changes
A documented rule can make the next import faster. Compare the next file's structure with the confirmed source convention and rerun a small representative review. Do not treat a previously successful conversion as a guarantee that a supplier will never change its export.
Reopen the process when a source, field meaning, locale or integration changes. Keep the same principle throughout: preserve what arrived, establish what it means and verify the date the team will use. That makes a booking list more dependable than a formatting fix applied after the ambiguity has already spread.
