4

I am processing records by pushing each record through validation stages, then into a database. One of the validation steps requires checking if certain columns are dates. I did this using DateTime.TryParse(s, out DateTime) assuming that this would use the configured Regional Settings on the machine on which the process was running. On my local machine, this is a wrapper class running within a command-line harness from Visual Studio (for ease of debugging). So 13/01/2010 gets formatted as 13 January 2010 as per the en-GB setting on my Windows 7 dev machine.

On pushing this onto our test server, a Windows Server 2008 R2, this wrapper class runs within a Window Service (under the LocalSystem account). Exactly the same code, I've designed it such that the service is just a thin wrapper. However, after many cycles of debugging, it seems the server is parsing 13/01/2010 as en-US and therefore failing. This is despite the Regional Settings being set to en-GB. (See screenshot)

Regional Settings on server

Note that this is way before it gets to SQL Server so that is not part of this issue.

After fighting with this, I've forced the situation by using the code below and setting the required format to en-GB.

Culture = CultureInfo.CreateSpecificCulture("en-GB");
DateTimeStyles dateTimeStyles = DateTimeStyles.None;
DateTime dt;
bool pass = DateTime.TryParse(s,Culture,dateTimeStyles, out dt);

This now works. My question is, how come the Windows Service, running under Local System assumes en-US and not en-GB?

Program.X
  • 7,250
  • 12
  • 49
  • 83

3 Answers3

3

Description

You can set the culture of the current thread to this using Thread.CurrentThread.CurrentCulture. This will have effect on all Culture specific things in the current thread.

Sample

Thread.CurrentThread.CurrentCulture = CultureInfo.GetCultureInfo("en-GB");

More Information

Update

It seems that your regional settings associated with your account profile are irrelevant when the service is running with the SYSTEM account. The default Culture for a windows service is en-US. There are many discussions on the web. All ending in "set the culture of the CurrentThread", like my answer.

dknaack
  • 60,192
  • 27
  • 155
  • 202
  • Although this helps, it doesn't really answer the question. His question was why his service doesn't pick the culture from the computer it's running on. – Ray Feb 03 '12 at 17:26
  • @Ray it seems there is no other way to do that. But i keep looking – dknaack Feb 03 '12 at 17:29
  • @dknacck. Okay, that's a bit of a rubbish situation. +1 – Ray Feb 03 '12 at 17:35
  • Lol. Thanks Ray and dknaacck. And yes, it is a pretty rubbish situation. And degrades my performance slightly, it seems. – Program.X Feb 05 '12 at 14:43
2

Resolved for me by setting the .net Globalization parameter "Set UI Culture".

On Windows 2008 server:

  • Load IIS manager

  • Go to the website

  • .net Globalization

  • Set UI Culture to "English (United Kingdom) (en-GB)"

Thanks

scott_lotus
  • 3,171
  • 22
  • 51
  • 69
  • thanks scott. This worked for me, after changing regional settings in control panel, and Thread.CurrentThread.CurrentCulture code in the answer, did not work – Shaakir Mar 03 '16 at 12:48
  • Thanks for the feed back , happy it helped. All the best. – scott_lotus Mar 03 '16 at 12:53
1

I have ran into this problem some days ago, after awhile I realize that my Application Pool Identity setting was set to Local system account, I changed it to you use custom account (Administator), so I don't need to set the culture of the current thread.

Andrew Barber
  • 39,603
  • 20
  • 94
  • 123
bui manhcuong
  • 51
  • 9