I have an app runing at a customer with international windows xp installations and the client reported to me that a few clients can not enter dates with their countries date-separator (.). The system is configured correctly. My app takes the separator from System.Globalization.DateTimeFormatInfo.CurrentInfo.DateSeparator. The version of .net is 3.5SP1.
Another issue that I have observed was during a presentation of another app of mine for another customer. The app changed the date output format during app runtime. Instead of showing dd.mm.yyyy, it changed to the us format mm/dd/yyyy after approximatively 1.5 hour of presentation. Because it was during presentation, I could not look what the problem was. I only restarted the app and all was fine again. The os on the presentation laptop was W7 en. Here I use DateTime.ToShortDateString.
My question is if, if also other programmers experiencing such obscure issues with globalization on international systems and if yes, if there are some does and donts. Or is there maybe a keyboard shortcut I’m not aware about, that changes the regional settings (not the keyboard layout, this one I’m aware about).
never ever rely on the final environment as well as configuration of installations for such issues. the best way to be 100% sure of the correct globalization (as well as localization) is to put all the checks in the code itself. when i know my app is going to be used in different locales, i explicitly get / set the current culture info via code. also, almost every parse method on common types (like numbers, datetime, etc) has an overload which lets you specify the culture info to be used while parsing culture specific data. are you ensuring this?
last but not the least, make sure your db server AS WELL AS your sps are correctly configured and coded for data input in different locales. for eg, sql server has plenty of options (including ISO standards) for date-time parsing / saving. sql server 2008 offers you much easier and better options for the same purpose
also, the golden rule with datetime is to ALWAYS SAVE THEM in UTC but display them based on current timezone / locale format. one very common mistake programmers make is to NOT save datetime info in UTC / GMT format in the db. for eg: instead of saving DateTime.UTCNow, they save DateTime.Now. i have seen days if not weeks spent on trying to figure out such bugs / issues when an app deals with multiple cultures / locales / timezones. and ditto while dealing with numbers. for eg: price of an item on an ecommerce site which deals which sells in multiple countries and currencies