468,533 Members | 1,903 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,533 developers. It's quick & easy.

Returning DateTime value ?

Hi,

Can a web service method return safely a DateTime value ? Would it cause
problems for non-.NET client proxy generators ?

Thanks

Navin
Nov 19 '05 #1
2 1450
Yes, it serializes datetime just fine. However: DateTime is always
serialized in local time, so if you consume/deserialize the soap
envelope in a different timezone you get a "different" datetime.

I put this in quotes because if you use local datetime, then it
represents the same point in time, just in different timezones. But if
you use a UTC datetime, .Net serializes it still as local time and you
really end up with a differnt datetime in a different timezone.

DateTime was not very well thought out in the first implementation and
mostly tuned for performance and compatibility, not for globalization.

More info on this issue:
http://blogs.msdn.com/bclteam/archiv...21/136918.aspx

To workaround this, tag the datetime as [XmlIgnore]/[SoapIgnore] and
instead serialize a string value of the datetime as described in the
above article.

I successfully used both approaches (DateTime serialization and
workaround) to create .Net webservices that are consumed by non .Net
clients (used Apache Axis and Glue Standard to create java stubs)

Nov 19 '05 #2
Thanks for response. The blog was very helpful. So, I understand it is safe
to return date time using the format yyyy-MM-ddTHH:mm:ss.fffffffzzz when
using local time. Would mobile toolkits like J2ME be able to consume this
format too ? And what about problem with COM and VBA clients as posted in
the blog ? Should the format always be yyyy-MM-dd HH:mm:ss ? But it doesn't
care of timezone.

Thanks again and regards

Navin
"Stefan" <Cl*********@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
Yes, it serializes datetime just fine. However: DateTime is always
serialized in local time, so if you consume/deserialize the soap
envelope in a different timezone you get a "different" datetime.

I put this in quotes because if you use local datetime, then it
represents the same point in time, just in different timezones. But if
you use a UTC datetime, .Net serializes it still as local time and you
really end up with a differnt datetime in a different timezone.

DateTime was not very well thought out in the first implementation and
mostly tuned for performance and compatibility, not for globalization.

More info on this issue:
http://blogs.msdn.com/bclteam/archiv...21/136918.aspx

To workaround this, tag the datetime as [XmlIgnore]/[SoapIgnore] and
instead serialize a string value of the datetime as described in the
above article.

I successfully used both approaches (DateTime serialization and
workaround) to create .Net webservices that are consumed by non .Net
clients (used Apache Axis and Glue Standard to create java stubs)

Nov 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by dkode8 | last post: by
1 post views Thread by Matthias De Ridder | last post: by
1 post views Thread by Matt Kemmerer | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.