What format should webservice DateTime be?
in [VB.NET]
|
From: Mark B on 11 Sep 2009 00:02 > 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. "Armin Zingler" <az.nospam(a)freenet.de> wrote in message news:%23psUqXnMKHA.3192(a)TK2MSFTNGP05.phx.gbl... > Mark B schrieb: >> 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 > > > > -- > Armin
From: Armin Zingler on 11 Sep 2009 05:35 Mark B schrieb: >> 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. 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. >> 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. 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. -- Armin
From: Andrew Morton on 11 Sep 2009 09:12 Mark B wrote: > 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? I would think following the standard would be best: http://en.wikipedia.org/wiki/ISO_8601 Andrew
From: Mark B on 14 Sep 2009 00:13
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... "bruce barker" <nospam(a)nospam.com> wrote in message news:e94ObQpMKHA.5072(a)TK2MSFTNGP05.phx.gbl... > 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) > > Mark B wrote: >> 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? >> >> >> >> >> >> >> >> |