Monday, 5 September 2011

The importance of regional settings

Today I hit another of those strange issues that plague our systems from time to time.

A web method was working in all our servers but one, which was a bit strange because that server had been tested before and found to be working OK. I asked the test team to pass me the SOAP request and after I switched trace logging on, it all became clear. The SOAP request contained this date (15/08/2011),  which explains why when it tried to convert it to a date it failed, as the system was using US date format.

No problem, I thought, I’ll just change the regional settings to UK settings, the problem was that the system already had its regional settings set to UK.

After a bit of search, I found this and added it to the web.config file:

<globalization    enableClientBasedCulture="true"   culture="auto:en-GB"    uiCulture="auto:en"/>

While it works, it left a bitter taste in my mouth. It seems too much like a hack.

I kept hunting for a better solution and it turns out that by default a remote user will get the default regional settings, which at the time were US settings. Thus, the service account, had US settings and was expecting US dates. I logged in with the service account, changed the settings to UK and it all works fine now.

For the record, you can check the regional settings for each user in this location  in the registry: HKEY_CURRENT_USER\Control Panel\International

No comments:

Post a Comment