1

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).

HCL
  • 36,053
  • 27
  • 163
  • 213

2 Answers2

2

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

Raj
  • 6,810
  • 6
  • 48
  • 56
  • +1 Thanks for the information and your experience. You are very clear on not using the system settings. But is this because you don't want to rely on an improperly configured system or because you don't trust the default globalization operations? Improperly configured systems are not my fear, my apps generally run in small environments (up to 100 clients) and therere I can tell the support to properly configure. The second one however is bad, I don't like it to build things the system already supports. They will lead almost always to unpractical behaviour in future versions... – HCL Jan 31 '11 at 13:15
  • hi hcl... my reasons for explicit code checks is coz i dont trust anybody with the right config / installation / support. but i do trust the .net framework... if a a lil bit of extra efforts and careful planning can get me rid of dependency on systems admin / support staff then why not :-) – Raj Jan 31 '11 at 13:28
1

The following answer contains valuable pointers on how the CultureInfo class can be utilized: How to honor/inherit user's language settings in WinForm app?

Community
  • 1
  • 1
basvo
  • 737
  • 1
  • 4
  • 12