Procedure consigliate per la serializzazione DateTime in .NET 3,5

Question

Circa 4 anni fa, ho seguito questo Articolo MSDN per le migliori pratiche di utilizzo di DateTime per la creazione di un client .Net su servizi Web .Net 1.1 e ASMX (con il server SQL 2000 come backend).Ricordo ancora i problemi di serializzazione che ho avuto con DateTime e lo sforzo di test necessario per i server con fusi orari diversi.

Le mie domande sono queste:Esiste un documento di best practice simile per alcune delle nuove tecnologie come WCF e SQL Server 2008, in particolare con l'aggiunta di nuovi tipi datetime per l'archiviazione di informazioni basate sul fuso orario.

Questo è l'ambiente:

1. SQL Server 2008 con ora del Pacifico.
2. Livello dei servizi Web su un fuso orario diverso.
3. I client potrebbero utilizzare .Net 2.0 o .Net 3.5 in diversi fusi orari.Se ciò semplifica, possiamo obbligare tutti a eseguire l'aggiornamento a .Net 3.5.:)

Qualche buon suggerimento/migliore pratica per i tipi di dati da utilizzare in ciascun livello?

Answer 1

Penso che il modo migliore per farlo sia passare sempre l'oggetto come UTC e convertirlo nell'ora locale sui client.In questo modo si crea un punto di riferimento comune per tutti i clienti.

Per convertire in UTC, chiamare ToUniversalTime sull'oggetto DateTime.Quindi, sui client, chiama ToLocalTime per ottenerlo nel fuso orario corrente.

Answer 2

Un grosso problema è che la serializzazione WCF non supporta xs:Date.Questo è un grosso problema perché se tutto ciò che desideri è una data, non dovresti essere costretto a preoccuparti dei fusi orari.Il seguente problema di connessione illustra alcuni dei problemi: http://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=349215

Se vuoi rappresentare un punto nel tempo in modo inequivocabile, ad es.non solo la parte della data, puoi usare la classe DateTimeOffset se hai .NET 3.5 sia sul client che sul server.Oppure, per l'interoperabilità, trasmetti sempre i valori di data/ora come UTC.

Answer 3

UTC/GMT sarebbe coerente in un ambiente distribuito.

Una cosa importante è specificare datetimeKind dopo aver popolato la proprietà DateTime con il valore del database.

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

Vedi MSDN

Answer 4

Finché il livello dei servizi Web e il livello client utilizzano il tipo DateTime .NET, dovrebbe serializzare e deserializzare correttamente come data/ora locale standard SOAP con informazioni sul fuso orario come:

09/15/2008 20:14:36

Se devi assolutamente conoscere il fuso orario stesso (ad es.quello sopra potrebbe essere l'ora solare orientale o l'ora legale centrale), è necessario creare il proprio tipo di dati che esponga tali parti come tali:

[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;
    }
}

allora la tua risposta sarebbe:

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

Answer 5

Ho avuto fortuna semplicemente mantenendo il tipo di dati DateTime e memorizzandolo sempre come GMT.In ogni livello, regolerei il valore GMT sul valore locale per il livello.