WCF的DateTimeOffset兼容性 [英] WCF DateTimeOffset compatibility

问题描述

我有一些业务合同，需要一个的DateTimeOffset一个.NET WCF服务。这样做是为了避免与DST和时区的混淆。

I have a .NET WCF service with a few operation contracts that takes a DateTimeOffset. The idea is to avoid any confusion with DST and time zones.

不过，我很怀疑，使用的DateTimeOffset是一个好主意，毕竟，因为它是相当不标准，会引起头痛，任何人试图用，比如连接，Java应用程序或.NET应用程序绑定到旧.NET版本。

However I am in doubt that using DateTimeOffset is a good idea after all, since it is fairly non-standard and would cause headaches for anyone trying to connect with, say, a Java application or a .NET application bound to an older .NET version.

另一种方法是期待一个UTC日期时间，但这会引入风险，有人会忘记使用UTC时间和本地时间调用该服务。 我还可以期待一个本地时间日期时间，因为客户总是会在同一个时区，但是这会使周围的DST更改一些细微的，但经典的，多义性。

An alternative is to expect a UTC DateTime, but this introduces the risk that someone will forget to use UTC time and call the service with a local time. I could also expect a local time DateTime, since clients will always be in the same timezone, but this leaves some subtle, but classic, ambiguity around DST changes.

有没有人有头痛的DateTimeOffset故事服务接口还是比较不成问题毕竟使用？

Does anyone have headache stories with DateTimeOffset in a service interface or is it relatively unproblematic to use after all?

推荐答案

目前，我正在改变我们的一些基础设施，WCF和偶然发现了这个悬而未决的问题，并决定试一试。 ：）

I'm currently changing some of our infrastructure to WCF and stumbled upon this unanswered question and decided to try it. :)

的方式，WCF序列化的DateTime 和的DateTimeOffset 似乎有点不可思议。如下面的示例所示，使用的DateTime 看起来是更好的选择与其他平台工作时：

The way that WCF serializes DateTime and DateTimeOffset seems to be a bit weird. As the following sample shows, using DateTime looks like the better option when working with other platforms:

using System;
using System.Runtime.Serialization;
using System.ServiceModel;

[ServiceContract]
public class DateTimeOffsetService
{
    [OperationContract]
    public Container DoWork()
    {
        return new Container
        {
            NowDateTime = DateTime.Now,
            UtcNowDateTime = DateTime.UtcNow,
            NowDateTimeOffset = DateTimeOffset.Now,
            UtcNowDateTimeOffset = DateTimeOffset.UtcNow
        };
    }
}

[DataContract]
public class Container
{
    [DataMember]
    public DateTime NowDateTime { get; set; }

    [DataMember]
    public DateTime UtcNowDateTime { get; set; }

    [DataMember]
    public DateTimeOffset NowDateTimeOffset { get; set; }

    [DataMember]
    public DateTimeOffset UtcNowDateTimeOffset { get; set; }
}

请求的响应XML是：

The response XML of the request is:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header />
  <s:Body>
    <DoWorkResponse xmlns="http://tempuri.org/">
      <DoWorkResult xmlns:a="http://schemas.datacontract.org/2004/07/RD.MES.WcfService" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
        <a:NowDateTime>2012-03-23T15:59:47.8328698+01:00</a:NowDateTime>
        <a:NowDateTimeOffset xmlns:b="http://schemas.datacontract.org/2004/07/System">
          <b:DateTime>2012-03-23T14:59:47.8328698Z</b:DateTime>
          <b:OffsetMinutes>60</b:OffsetMinutes>
        </a:NowDateTimeOffset>
        <a:UtcNowDateTime>2012-03-23T14:59:47.8328698Z</a:UtcNowDateTime>
        <a:UtcNowDateTimeOffset xmlns:b="http://schemas.datacontract.org/2004/07/System">
          <b:DateTime>2012-03-23T14:59:47.8328698Z</b:DateTime>
          <b:OffsetMinutes>0</b:OffsetMinutes>
        </a:UtcNowDateTimeOffset>
      </DoWorkResult>
    </DoWorkResponse>
  </s:Body>
</s:Envelope>

我在GMT + 01.00时区，所以价值观似乎是正确的。为什么这样说？那么，WSDL定义容器是这样的：

<xs:schema elementFormDefault="qualified" targetNamespace="http://schemas.datacontract.org/2004/07/WcfService">
    <xs:import schemaLocation="http://localhost:3608/DateTimeOffsetService.svc?xsd=xsd3" namespace="http://schemas.datacontract.org/2004/07/System"/>
    <xs:complexType name="Container">
        <xs:sequence>
            <xs:element minOccurs="0" name="NowDateTime" type="xs:dateTime"/>
            <xs:element minOccurs="0" name="NowDateTimeOffset" type="q1:DateTimeOffset"/>
            <xs:element minOccurs="0" name="UtcNowDateTime" type="xs:dateTime"/>
            <xs:element minOccurs="0" name="UtcNowDateTimeOffset" type="q2:DateTimeOffset"/>
        </xs:sequence>
    </xs:complexType>
    <xs:element name="Container" nillable="true" type="tns:Container"/>
</xs:schema>

和的DateTimeOffset - 在WSDL中 - 被定义为：

And DateTimeOffset - in WSDL - is defined as:

<xs:schema elementFormDefault="qualified" targetNamespace="http://schemas.datacontract.org/2004/07/System">
    <xs:import schemaLocation="http://localhost:3608/DateTimeOffsetService.svc?xsd=xsd1" namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>
    <xs:complexType name="DateTimeOffset">
        <xs:annotation>
            <xs:appinfo>
                <IsValueType>true</IsValueType>
            </xs:appinfo>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="DateTime" type="xs:dateTime"/>
            <xs:element name="OffsetMinutes" type="xs:short"/>
        </xs:sequence>
    </xs:complexType>
    <xs:element name="DateTimeOffset" nillable="true" type="tns:DateTimeOffset"/>
</xs:schema>

因此​​，基本上，的DateTime 被序列为标准的xs：日期时间（里面确实有正确的时区组件）和的DateTimeOffset 序列化为非标准复杂类型，调用者就必须正确认识和处理。

So basically, DateTime is serialized as a standard xs:dateTime (which does have the correct timezone component) and DateTimeOffset is serialized into a non-standard complex type, which the caller would have to understand and handle correctly.

FWIW;因为我发现了这一点，我可能会使用的DateTime 为WCF接口，除非我真的需要采取不同的时区偏移的照顾。

FWIW; Since I found this out, I will probably use DateTime for the WCF interface unless I actually need to take care of different timezone offsets.

目前，唯一的理由我会倾向于使用复杂类型看（因为的xs：日期时间应该能够包含它的所有信息）是如果的xs：日期时间已被用于序列化的DateTime 和的DateTimeOffset ，WCF客户端将不知道使用哪种类型的。

Currently, the only justification I could see in favour of using the complex type (since xs:dateTime should be able to contain all information that it does!) is that if xs:dateTime had been used to serialize DateTime and DateTimeOffset, a WCF client would have no idea which type to use.

这篇关于WCF的DateTimeOffset兼容性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！