Returning DateTime value ?

[Navin Mishra]

Hi,

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

Thanks

Navin

[Stefan]

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)

[Navin Mishra]

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.fff ffffzzz 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*********@gm ail.com> wrote in message
news:11******** **************@ g44g2000cwa.goo glegroups.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)