Best Practices für die Datetime Serialisierung in .NET 3.5

Question

Einige 4 Jahre zurück, folgte ich diesen MSDN-Artikel für Datetime beste Nutzungspraktiken für den Aufbau einen .Net-Client auf .Net 1.1 und ASMX Web Service (mit SQL 2000 Server als Backend). Ich erinnere mich noch an die Serialisierung Probleme ich mit Datetime hatte und den Testaufwand für Server in verschiedenen Zeitzonen hat.

Meine Fragen sind diese: Gibt es ein ähnliches Dokument Best Practices für einige der neuen Technologien wie WCF und SQL Server 2008 vor allem mit dem Zusatz von neuem Datetime-Typ für Zeitzone bewusst info speichern

.

Dies ist die Umwelt:

1. SQL Server 2008 auf Pacific Time.
2. Web Services-Schicht auf einer anderen Zeitzone.
3. Clients verwendet werden könnte .Net 2.0 oder .NET 3.5 auf verschiedenen Zeitzonen. Wenn es es einfach macht, können wir alle zwingen, .Net 3.5 zu aktualisieren. :)

Jede gute Vorschläge / Best Practices für die Datentypen in jeder Schicht verwendet werden?

Answer 1

Ich denke, der beste Weg, dies zu tun, ist immer das Objekt als UTC passieren und in der lokalen Zeit auf den Clients zu konvertieren. Dadurch gibt es einen gemeinsamen Bezugspunkt für alle Kunden.

, um UTC zu konvertieren, rufen ToUniversalTime auf dem Objekt Datetime. Dann auf den Clients, ToLocalTime nennen sie in ihrer aktuellen Zeitzone zu erhalten.

Answer 2

Ein großes Problem ist, dass WCF-Serialisierung nicht xs unterstützt: Datum. Dies ist ein großes Problem, als ob alles, was Sie wollen ein Datum ist, sollten Sie nicht zu besorgt über Zeitzonen gezwungen werden. Die folgende connect Ausgabe beschreibt einige der Probleme: http://connect.microsoft .com / wcf / Feedback / ViewFeedback.aspx? FeedbackID = 349.215

Wenn Sie einen Zeitpunkt darstellen wollen eindeutig, das heißt nicht nur der Datumsteil, können Sie die Datetime Klasse verwenden, wenn Sie .NET 3.5 auf Client und Server haben. Oder für die Interoperabilität, passieren immer Datums- / Zeitwerte wie UTC.

Answer 3

UTC / GMT würde in verteilten Umgebung in Einklang steht.

Eine wichtige Sache ist, dass das Datetimekind gibt nach dem Datetime-Eigenschaft mit dem Wert aus der Datenbank bevölkert.

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

MSDN

Answer 4

Solange Ihre Web-Services-Schicht und Client-Schicht, die den .NET Datetime-Typen verwenden, sollte es serialisiert und richtig als SOAP-Standard lokales Datum / Zeit w / Zeitzone Informationen wie deserialisieren:

2008-09-15T13: 14: 36,9502109-05: 00

Wenn Sie absolut müssen sich positiv auf die Zeitzone wissen selbst (das heißt, die oben könnte Eastern Standard Time oder Zentral Daylight Time sein), müssen Sie Ihre eigenen Datentyp schaffen, die diese Stücke als solche entlarvt:

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

Sie dann Ihre Antwort würde wie folgt aussehen:

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

Answer 5

Ich hatte viel Glück mit nur den Datetime-Datentyp zu halten und immer als GMT speichern. In jeder Schicht, würde ich den GMT-Wert auf den lokalen Wert für die Schicht einzustellen.