>>For now I just added the cultureinfo into the Convert function. I think with the 99.999% probability the date either will come in ISO format or us-locale.
>>
>>However, I'm not 100% sure. I was thinking perhaps I may need to figure out what format is used with the RegEx, but that may be an overkill.
>>
>>At least for now I would assume that the coming date string is either ISO or us-locale.
>
>If there is a free data entry format text for a string date somewhere by a user, then there is something missing. It is either the interface has a control to allow the user to select a date, into which you can rely on a given format, or, if the user enters the date in a free format string, then, there should be indication beside it as to know what would be the required format.

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.

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.

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.