What format should webservice DateTime be?

  • Thread starter Thread starter Mark B
  • Start date Start date
M

Mark B

Our webservice from a server is Florida is returning date strings in the
format:

"04/10/2009 2:12:25 p.m.|"

i.e. "mm/dd/yyyy hh:nn:ss a.m/p.m.", that is April 10, 2009


However when we consume the webservice via a local C# app, if the app is in
New Zealand, it treats the date as being October 4, 2009 since New Zealand
uses "dd/mm/yyyy hh:nn:ss a.m/p.m.", not "mm/dd/yyyy hh:nn:ss a.m/p.m.".


What's the best way for the webservice to return a DateTime value so it is
understood no matter where in the world it is consumed?
 
Mark said:
Our webservice from a server is Florida is returning date strings in the
format:

"04/10/2009 2:12:25 p.m.|"

i.e. "mm/dd/yyyy hh:nn:ss a.m/p.m.", that is April 10, 2009


However when we consume the webservice via a local C# app, if the app is in
New Zealand, it treats the date as being October 4, 2009 since New Zealand
uses "dd/mm/yyyy hh:nn:ss a.m/p.m.", not "mm/dd/yyyy hh:nn:ss a.m/p.m.".


What's the best way for the webservice to return a DateTime value so it is
understood no matter where in the world it is consumed?
Click to expand...

How do you convert the String to DateTime? Try DateTime.ParseExact
instead (note that month=MM (capitals) and minutes=mm).
 
Thanks. I'll look into how the local C# app is parsing.

I figured the "MM" too when "mm" was not working.

I'm thinking I might use the following in the webservice in case the webhost
people in Florida decide to change the format of their datetime. Otherwise
if I used parse exact it might not work if they changed their format:


Function fWsDateFormat(ByVal dtRawDate As Object) As String

'Convert date time to standardized string
'---------------------------------------------
Dim strDateTimeStringFormat As String = "yyyy-MM-dd hh:mm:ss tt"
If dtRawDate.ToString = "" Then
Return ""
End If
Return Format(dtRawDate, strDateTimeStringFormat)

End Function


Hopefully then no matter which country the app was in, it would interpret
the date the same.
 
Mark said:
Thanks. I'll look into how the local C# app is parsing.

I figured the "MM" too when "mm" was not working.

I'm thinking I might use the following in the webservice in case the webhost
people in Florida decide to change the format of their datetime. Otherwise
if I used parse exact it might not work if they changed their format:


Function fWsDateFormat(ByVal dtRawDate As Object) As String

'Convert date time to standardized string
'---------------------------------------------
Dim strDateTimeStringFormat As String = "yyyy-MM-dd hh:mm:ss tt"
If dtRawDate.ToString = "" Then
Return ""
End If
Return Format(dtRawDate, strDateTimeStringFormat)

End Function

Hopefully then no matter which country the app was in, it would interpret
the date the same.
Click to expand...


In what way does this help solve the aforementioned problem? This
function converts into a String but not the other way round.

How will you know the new format if it will be changed? Isn't it
possible to get the values as a DateTime or DateTimeOffset object? When
working with dates/times, they should not be held in Strings. Only the
user interface frontend should deal with a certain format and the
conversion from/to String.

It's more secure to narrow down types as good as possible. Is there a
reason why the argument's type is 'Object'? If you pass a Form it will
fail at runtime. With a DateTime object, you can go the straight way
by calling dtRawDate.ToString(<format>).


See also "Working with base types":
http://msdn.microsoft.com/en-us/library/7wchwf6k.aspx
 
you should use the gmt time format (RFC 1123). Also be sure to convert
local date/time to gmt:

var date = DateTime.Now;
var utcdate = new DateTimeOffset(date,
TimeZoneInfo.Local.GetUtcOffset(date1);
var webDate = utcDate.ToUniversalTime().ToString("r");

-- bruce (sqlwork.com)
 
In what way does this help solve the aforementioned problem? This
function converts into a String but not the other way round.
Click to expand...

That's a function in the webservice that I have introduced (we wrote the
webservice). It just means the webservice delivers the date string that way.

I believe that yyyy-MM-dd will always be interpreted by .Net as yyyy-MM-dd
regardless of whether the local user has US (MM-DD-YYYY) or New Zealand
(DD-MM-YYYY) date format set in their control panel. The same doesn't apply
for "07/07/2009".

My lead programmer used datetime strings since he is returning webservice
values pipe-separated with an asterisk for end of record:

3|2009-09-07 12:00:00 a.m.|2009-09-12 12:00:00
a.m.|True||24|4320|||2008-10-05 12:00:00 a.m.||Joe|Smith*
7|2009-09-07 12:00:00 a.m.|2009-09-12 12:00:00
a.m.|True||7200|7200|||2009-02-07 12:00:00 a.m.||Mary|Brown*
11|2009-09-07 12:00:00 a.m.|2009-09-12 12:00:00
a.m.|True||60|7200|||2009-02-07 12:00:00 a.m.||Ken|Jones*

He said there was no need to use XML. I'm not 100% sure that's the best
practice though he's the computer science grad.

I had thought of using 37098.4323 format for the date but don't mind being
able to see the values without needing to convert them as above.


It's more secure to narrow down types as good as possible. Is there a
reason why the argument's type is 'Object'? If you pass a Form it will
fail at runtime. With a DateTime object, you can go the straight way
by calling dtRawDate.ToString(<format>).
Click to expand...

I thought I might get an error if the incoming dtRawDate was Null.
 
Mark said:
That's a function in the webservice that I have introduced (we wrote the
webservice). It just means the webservice delivers the date string that way.
Click to expand...

Ahh, I see now. I thought you consume the String from the
service. Now it's clear.
I believe that yyyy-MM-dd will always be interpreted by .Net as yyyy-MM-dd
regardless of whether the local user has US (MM-DD-YYYY) or New Zealand
(DD-MM-YYYY) date format set in their control panel. The same doesn't apply
for "07/07/2009".

My lead programmer used datetime strings since he is returning webservice
values pipe-separated with an asterisk for end of record:

3|2009-09-07 12:00:00 a.m.|2009-09-12 12:00:00
a.m.|True||24|4320|||2008-10-05 12:00:00 a.m.||Joe|Smith*
7|2009-09-07 12:00:00 a.m.|2009-09-12 12:00:00
a.m.|True||7200|7200|||2009-02-07 12:00:00 a.m.||Mary|Brown*
11|2009-09-07 12:00:00 a.m.|2009-09-12 12:00:00
a.m.|True||60|7200|||2009-02-07 12:00:00 a.m.||Ken|Jones*

He said there was no need to use XML. I'm not 100% sure that's the best
practice though he's the computer science grad.
I had thought of using 37098.4323 format for the date but don't mind being
able to see the values without needing to convert them as above.
Click to expand...





I haven't written and used a web service so far, so I think someone else
could help you better. Though, with XML it would not have been a problem
because there is a default conversion from/to String if the data type
(DateTime) is known.

But anyway, before now, it wasn't clear to me that there are actually
two issues: a) The date/time format b) the time zone. The time zone is
not returned from the web service. Without this information, any
application consuming the service would have to either guess or know it,
which means hard-coding it. If the web service' local time zone is not
of interest, there must be a agreement which time zone it is. Only UTC
makes sense, IMO. So, if the consumers know that it's UTC, they can
easily convert from that time zone to their local time zones.

I thought I might get an error if the incoming dtRawDate was Null.
Click to expand...

Ok, but in that case I'd at least restrict it at runtime. Something like

shared Function fWsDateFormat(ByVal dtRawDate As Object) As String

'Convert date time to standardized string
'---------------------------------------------
Dim strDateTimeStringFormat As String = "yyyy-MM-dd hh:mm:ss tt"
if dtRawDate is dbnull.value then
Return ""
elseif typeof dtRawDate is datetime then
Return dtRawDate.tostring(strDateTimeStringFormat)
else
'throw exception here
End If

End Function

In addition a Nullable(of DateTime) could be used.
Well, only a side note.
 
Actually I wrote the web service's SQL database including stored procedures.

Looking back on it now I think it may have been better if I used
GetUtcDate() instead of GetDate() all over the place.

Worth a change now I wonder? ...

I'd have to then go and see if any asp.net code for the webservices had
Now() code in...
 
Back
Top