I've recently added WEB API to an existing VS desktop application and everything worked fine, until yesterday when I had to add a GET method that took three parameters, one of them a Date. Well, at first I thought that that was going to be a piece of cake, but much to my surprise I noticed that when I sent 2014/07/09 (9th July) on the server where the application was installed it was treated like 2014/09/07 (7th September) and for that reason all my comparisons never worked.
I have tried things like changing from a GET method to a POST method, changing my Regional and Language Options settings to the same on the server, passing the date as a String a created a Datetime object on the server using the parts of the string. Unfortunately none of them worked.
Then I remember that this desktop application have some methods on its WCF project (which I'm passing now to web API) that passed dates with no problem at all. Looking in the code for a while I found that they used something like this on every class of they WCF project that uses dates:
Imports System.Globalization
Imports System.Security.Permissions
Imports System.Threading
Public Class ServicioRemotoVentas
Implements IServicioRemotoVentas
Public Sub New()
MyBase.New()
Thread.CurrentThread.CurrentCulture = New CultureInfo("es-PE", False)
End Sub
Surely this Thread.CurrentThread.CurrentCulture = New CultureInfo("es-PE", False), must be there for something. Now I would like to know if you have used something like that in Web API before? if so how and where did you put such a configuration.
These are the settings on my pc :
And these are the server settings:
I almost forgot to mention that I pass all the dates using this format yyyy/M/d with all the other parameters using json. Is it perhaps that when the string is deserialized in the Web API this is done using the system date format because I haven't specify the culture info to use?? or maybe it is a Json error when trying serialize/deserialize the dates??
As always, any advice or resources you could provide would be greatly appreciated.
As discussed in the comments, the ASP.NET runtime does have a solution for these scenarios: it is the web.cofig
element <globalization>
- (see MSDN <globalization>
Element)
It's structure is defined as:
<configuration>
<system.web>
<globalization
enableClientBasedCulture="true|false"
requestEncoding="any valid encoding string"
responseEncoding="any valid encoding string"
fileEncoding="any valid encoding string"
responseHeaderEncoding = "any valid encoding string"
resourceProviderFactoryType = string
enableBestFitResponseEncoding = "true|false"
culture="any valid culture string"
uiCulture="any valid culture string"/>
So, in case, that we want to force server/dev workstation to act in en-US
culture we should use these explicit settings:
<globalization
enableClientBasedCulture="false"
uiCulture="en-US"
culture="en-US" />
This will use the proper (desired and set) culture for any http request.
Also interesting could be the default setting overview:
<globalization
requestEncoding="utf-8"
responseEncoding="utf-8"
fileEncoding=""
culture=""
uiCulture=""
enableClientBasedCulture="false"
responseHeaderEncoding="utf-8"
resourceProviderFactoryType=""
enableBestFitResponseEncoding="false" />
See also similar here: