What format should webservice DateTime be?

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?
 
A

Armin Zingler

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?

How do you convert the String to DateTime? Try DateTime.ParseExact
instead (note that month=MM (capitals) and minutes=mm).
 
M

Mark B

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.
 
A

Armin Zingler

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.


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
 
B

bruce barker

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)
 
M

Mark B

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

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>).

I thought I might get an error if the incoming dtRawDate was Null.
 
A

Armin Zingler

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.

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.





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.

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.
 
M

Mark B

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...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top