I am not sure whether this is as expected. In any case it currently requires care.
My system locale is set to English (New Zealand), which uses short date format d/MM/yyyy, the same as English (Australia), and almost the same format as English (United Kingdom), French (France), Spanish (Spain) and others, which all use dd/MM/yyyy. German (Germany) and Russian (Russia) both use dd.MM.yyyy. These selected examples use the same day-month order, with small variations.
By contrast, English (United States) uses M/d/yyyy, month first.
This is well known.
But look what happens in SQL9. Again, my locale is set to use d/MM/yyyy.
? DateTimeDay(CAST('6/4/1920 0:00:00' AS DATETIME))
? DateTimeDay(CAST('6/04/1920 0:00:00' AS DATETIME))
? DateTimeDay(CAST('4/6/1920 0:00:00' AS DATETIME))
? DateTimeDay(CAST('12/31/1920 0:00:00' AS DATETIME))
? DateTimeDay(CAST('31/12/1920 0:00:00' AS DATETIME))
In other words, date-time strings are being interpreted as if they were expressed in US order, not local order--except where that is not possible (the last example).
(Results are the same if we leave off the time part of each string.)
This looks like a serious trap, with errors that will not always be obvious.