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. --SQL9 ? DateTimeDay(CAST('6/4/1920 0:00:00' AS DATETIME)) --> 4 ? DateTimeDay(CAST('6/04/1920 0:00:00' AS DATETIME)) --> 4 ? DateTimeDay(CAST('4/6/1920 0:00:00' AS DATETIME)) --> 6 ? DateTimeDay(CAST('12/31/1920 0:00:00' AS DATETIME)) --> 31 ? DateTimeDay(CAST('31/12/1920 0:00:00' AS DATETIME)) --> 31 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.
|