>Both our applications are supposed to respect client's locale. So, I think Sales application also supposed to get the date in the Spanish locale eventually.
There is nothing wrong in detecting the local settings and act accordingly. The issue I raised is that if someone is able to enter a date value, as is, into a text field, thus a string, no matter the local settings or what the application expects, there will always be no guarantee into which formats the person enters the data. However, the validation may enforce the date value to respect the user setting. But, then again, there is no logical or articial way of detecting what the user had in mind when entering 06/12/2017 or 12/06/2017.
>However, the current string contained the date in US format and the middleware dll was failing processing that date correctly. The client's locale is Spanish.
Between tiers, a protocol would then need to be established to ensure a proper way of communicating such value up until the storage. From what I understand, I believe you have that part resolved. The main concern appears to be the data collected from the user into a free format. In here, for example, at first, and from the first wave of Web apps, many were collecting data into a text field, for a date value, or from a date picker selection into the text field, thus resulting in the same ending as the user can still change the way the date is entered, as far as month/day for example, unless the shown selected value into a textbox field is read only. Now, you mostly see user friendly controls such as when doing a search into where you could see I use dropdowns for each value and that also makes sure we won't have any problem with the date format. I would probably add a vote to use a similar approach for Winforms (desktop apps), when collecting date values, in favor or eliminating the free format data collect. Fast typers may not like it as they don't like to use the mouse to select a value or a date picker. But, there is a trend, and it is gearing more towards avoiding typing when collecting data as much as possible so to ease the process or collecting and validating the data, which is also more interesting on mobile devices as many simply hates to type on those devices.
>On the other hand, perhaps we should demand the date to be sent back and forth in the consistent format. I think right now we're formatting dates into US-locate format on the way out (I'll double check our code) and we probably should also expect consistent US-locale format.
>It may be a presentation problem, though. Sounds like we may want to discuss this problem in more depth in our meetings.
The transporation of the date value between various layers shouldn't be of a concern. It appears this mostly relies on the data entry itself into where some fine tuning may apply. Once I have a date collected into an application, whenever I have to transport it between classes and storage, it is only a matter of using a date value without any need to know into which format it was entered. If you do have to support a full text data entry for date values, then, you could also bounce the expected and required format from the user settings into his account, such as this site, into where a user decides which format to use, or to use it from the local settings. But, there would still be a need to validate againsts that expected format as a full text data entry support allows a user to enter a date value in any format he wants.
