I've searched everywhere and can't find the answer. I would like to understand what's going with the way I format the datetime (with timezone) url parameter.
Here is the situation:
Here are the test cases:
Case 1: This one works
http://******/api/ItemSource/GetItemSourceOption?OrganizationCode=OKC&PoCreationDate=2018-10-08T01:02:03.0000000-05:00
Case 2: This one does not work and the browser is displaying
<Error>
<Message>The request is invalid.</Message>
</Error>
http://******/api/ItemSource/GetItemSourceOption?OrganizationCode=OKC&PoCreationDate=2018-10-08T05:00:00.0000000+00:00
Notice the different? one of them have a -05:00 the other have +00:00. My timezone is Central (which is -05:00 right now?)
Case 3: My current work around is to format it this way http://******/api/ItemSource/GetItemSourceOption?OrganizationCode=OKC&PoCreationDate=2018-10-08T05:00:00Z
=====================
So I am just trying to understand what's going on here and these my thoughts...
I believe that using the Z format is the best solution since the DateTime value (from the source) is always in UTC format.
About the -05:00 and +00:00, are these supposed to be set per the receiver's timezone (the destination Server local timezone)? So for this case, my PC is the receiver (WebAPI) and it's set to Central Time Zone, therefore this value must be -05:00 to represent the current value for Central Time Zone?
Please help me understand this. Thanks.
The +
character in the offset is being interpreted as a space, as per URL encoding rules. You will need to encode it, such that it is replaced with %2B
.
If you are building this URL from JavaScript, use the encodeURIComponent
function.
If you are building it in C#, use the System.Net.WebUtility.UrlEncode
method.
Note that doing so will also replace the :
characters with %3A
, which is optional in a querystring parameter, but still recommended.
In general, parameters passed in the querystring need to be encoded, unless you can guarantee that they contain no special characters.
Also, you may want to ask yourself if this field really needs to be a full date+time+offset. In many cases, one might expect a field like PoCreationDate
to be just a date, as in "2018-10-08"
. Of course, that depends on your application logic and business requirements.