Les meilleures pratiques pour le type DateTime de sérialisation dans .NET 3.5

Environ 4 ans en arrière, j'ai suivi ce Article MSDN pour DateTime l'utilisation des meilleures pratiques pour la construction d'un .Net client sur .Net 1.1 et services web ASMX (avec SQL 2000 server comme le backend). Je me souviens encore de la sérialisation des problèmes que j'ai eu avec DateTime et de l'effort de test, il a fallu pour les serveurs dans des fuseaux horaires différents.

Ma questions est la suivante: Est-il un semblable document sur les pratiques exemplaires pour certaines des nouvelles technologies comme la WCF, SQL server 2008, notamment avec l'ajout de nouveaux types datetime pour le stockage de fuseau horaire au courant de l'info.

C'est l'environnement:

  1. SQL server 2008 sur l'Heure du Pacifique.
  2. Couche de Services Web sur un fuseau horaire différent.
  3. Les Clients pourraient être en utilisant .Net 2.0 ou .Net 3.5 sur des fuseaux horaires différents. Si il est facile, nous pouvons forcer tout le monde à la mise à niveau vers .Net 3.5. 🙂

Toutes les bonnes suggestions/les meilleures pratiques pour les types de données à utiliser dans chaque couche?

InformationsquelleAutor Gulzar Nazim | 2008-09-15
  1. 18

    Je pense que la meilleure façon de le faire est de toujours passer de l'objet que l'UTC, et de les convertir à l'heure locale sur les clients. Ce faisant, il est un point de référence commun pour tous les clients.

    À se convertir à l'UTC, appel ToUniversalTime sur l'objet DateTime. Ensuite, sur les clients, appel ToLocalTime pour l'obtenir dans leur fuseau horaire actuel.

    • Notez que le client reçoit le datetime nature Unspecified. Lorsque vous appelez ToUniversalTime, il se supposer Local de temps et de réellement faire une conversion. La bonne façon serait de faire DateTime.SpecifyKind(myUtcTime, DateTimeKind.Utc) au lieu de ToUniversalTime.
    InformationsquelleAutor Abe Heidebrecht
  2. 12

    Un gros problème, c'est que WCF la sérialisation ne prend pas en charge xs:Date. C'est un gros problème, comme si tout ce que vous voulez, c'est une date, vous ne devriez pas être forcé à être concernés sur les fuseaux horaires. La suite se connecter numéro traite de certains problèmes: http://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=349215

    Si vous voulez représenter un point dans le temps sans ambiguïté, c'est à dire pas seulement la partie de la date, vous pouvez utiliser le DateTimeOffset classe si vous en avez .NET 3.5 sur à la fois le client et le serveur. Ou pour l'interopérabilité, toujours passer des valeurs de date/heure UTC.

    InformationsquelleAutor Joe
  3. 4

    UTC/GMT serait conforme en environnement distribué.

    Une chose importante est de préciser que les datetimeKind après le remplissage de votre DateTime propriété avec la valeur de la base de données.

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

    Voir MSDN

    InformationsquelleAutor Ray Lu
  4. 2

    Tant que votre couche de services web et client de la couche d'utiliser l' .NET type DateTime, il devrait sérialiser et désérialiser correctement comme un SAVON-norme locale de date/heure w/Timezone des informations telles que:

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

    Si vous avez absolument, positivement devez connaître le fuseau horaire lui-même (c'est à dire la-dessus pourrait être Heure normale de l'est ou Centrale l'Heure d'été), vous devez créer votre propre type de données qui expose ces pièces en tant que tel:

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

    alors votre réponse serait:

    <Now>2008-09-15T13:34:08.0039447-05:00</Now>
<TimeZone>Central Daylight Time</TimeZone>
<IsDaylightSavingTime>true</IsDaylightSavingTime>
    • C'est maintenant, comment WCF semble fonctionner. Je ne suis pas d'obtenir quoi que ce soit indiquant fuseau horaire (c'est à dire -05:00).
    InformationsquelleAutor Jesse C. Slicer
  5. 1

    J'ai eu de la chance avec juste de garder le type de données DateTime et toujours stocker GMT. Dans chaque couche, j'avais régler le GMT de la valeur à la valeur locale de la couche.

    InformationsquelleAutor Mark