it-swarm-pt.tech

Práticas recomendadas para serialização DateTime no .NET 3.5

Há cerca de 4 anos, segui isso artigo do MSDN para obter as melhores práticas de uso do DateTime para criar um cliente .Net nos serviços da web .Net 1.1 e ASMX (com o servidor SQL 2000 como back-end). Ainda me lembro dos problemas de serialização que tive com o DateTime e do esforço de teste necessário para servidores em diferentes fusos horários.

Minhas perguntas são: Existe um documento de práticas recomendadas semelhante para algumas das novas tecnologias, como o WCF e o SQL Server 2008, especialmente com a adição de novos tipos de data e hora para armazenar informações com reconhecimento de fuso horário.

Este é o ambiente:

  1. SQL Server 2008 no horário do Pacífico.
  2. Camada de serviços da Web em um fuso horário diferente.
  3. Os clientes podem estar usando .Net 2.0 ou .Net 3.5 em diferentes fusos horários. Se isso facilitar, podemos forçar todos a atualizar para o .Net 3.5. :)

Alguma boa sugestão/prática recomendada para os tipos de dados a serem usados ​​em cada camada?

21
Gulzar Nazim

Eu acho que a melhor maneira de fazer isso é sempre passar o objeto como UTC e converter para o horário local nos clientes. Ao fazer isso, há um ponto de referência comum para todos os clientes.

Para converter para UTC, chame ToUniversalTime no objeto DateTime. Em seguida, nos clientes, chame ToLocalTime para obtê-lo no fuso horário atual.

18
Abe Heidebrecht

Um grande problema é que a serialização do WCF não suporta xs: Date. Esse é um grande problema, como se tudo o que você quer fosse uma data, não se preocupe com os fusos horários. O seguinte problema de conexão discute alguns dos problemas: http://connect.Microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=349215

Se você quiser representar um ponto no tempo sem ambiguidade, ou seja, não apenas a parte da data, poderá usar a classe DateTimeOffset se tiver o .NET 3.5 no cliente e no servidor. Ou, para interoperabilidade, sempre passe valores de data/hora como UTC.

12
Joe

UTC/GMT seria consistente em ambiente distribuído.

Uma coisa importante é que especifique o datetimeKind depois de preencher sua propriedade DateTime com o valor do banco de dados.

dateTimeValueUtcKind = DateTime.SpecifyKind(dateTimeValue, DateTimeKind.Utc);

Consulte MSDN

4
Ray Lu

Desde que a camada de serviços da Web e a camada do cliente usem o tipo .NET DateTime, ela deve serializar e desserializar adequadamente como uma data/hora local padrão do SOAP com informações de fuso horário, como:

2008-09-15T13: 14: 36.9502109-05: 00

Se você absolutamente, positivamente, deve conhecer o fuso horário em si (ou seja, o acima pode ser o horário padrão do leste ou o horário de verão central), é necessário criar seu próprio tipo de dados que expõe essas peças como:

[Serializable]
public sealed class MyDateTime
{
    public MyDateTime()
    {
        this.Now = DateTime.Now;
        this.IsDaylightSavingTime = this.Now.IsDaylightSavingTime();
        this.TimeZone = this.IsDaylightSavingTime
            ? System.TimeZone.CurrentTimeZone.DaylightName
            : System.TimeZone.CurrentTimeZone.StandardName;
    }

    public DateTime Now
    {
        get;

        set;
    }

    public string TimeZone
    {
        get;

        set;
    }

    public bool IsDaylightSavingTime
    {
        get;

        set;
    }
}

então sua resposta seria semelhante a:

<Now>2008-09-15T13:34:08.0039447-05:00</Now>
<TimeZone>Central Daylight Time</TimeZone>
<IsDaylightSavingTime>true</IsDaylightSavingTime>
2
Jesse C. Slicer

Tive sorte em manter o tipo de dados DateTime e sempre armazená-lo como GMT. Em cada camada, eu ajustaria o valor GMT ao valor local da camada.

1
Mark