Méthodes conseillées pour la sérialisation DateTime dans .NET 3.5

Question

Il y a environ 4 ans, j'ai suivi cet article MSDN pour DateTime Utilisation des meilleures pratiques pour la création d'un client .Net sur des services Web .Net 1.1 et ASMX (avec le serveur SQL 2000 en tant que serveur principal). Je me souviens encore des problèmes de sérialisation que j’avais avec DateTime et des efforts de test qu’il a fallu pour les serveurs situés dans différents fuseaux horaires.

Mes questions sont les suivantes: existe-t-il un document sur les meilleures pratiques pour certaines des nouvelles technologies telles que WCF et SQL Server 2008, en particulier avec l'ajout de nouveaux types de date / heure pour stocker les informations tenant compte des fuseaux horaires.

Voici l'environnement:

1. SQL Server 2008 à l'heure du Pacifique.
2. Couche Services Web sur un fuseau horaire différent.
3. Les clients pourraient utiliser .Net 2.0 ou .Net 3.5 sur différents fuseaux horaires. Si cela vous facilite la tâche, nous pouvons obliger tout le monde à passer à .Net 3.5. :)

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

Answer 1

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

Pour convertir en UTC, appelez ToUniversalTime sur l'objet DateTime. Ensuite, sur les clients, appelez ToLocalTime pour l’obtenir dans leur fuseau horaire actuel.

Answer 2

Un gros problème est que la sérialisation WCF ne prend pas en charge xs: Date. C'est un gros problème car si tout ce que vous voulez, c'est une date, vous ne devriez pas être obligé de vous préoccuper des fuseaux horaires. Le problème de connexion suivant traite de certains des problèmes: http://connect.microsoft .com / wcf / feedback / ViewFeedback.aspx? FeedbackID = 349215

Si vous souhaitez représenter un point dans le temps sans ambiguïté, c’est-à-dire pas seulement la partie date, vous pouvez utiliser la classe DateTimeOffset si vous disposez de .NET 3.5 sur le client et le serveur. Pour l’interopérabilité, transmettez toujours les valeurs de date / heure au format UTC.

Answer 3

UTC / GMT serait cohérent dans un environnement distribué.

Une chose importante est de spécifier datetimeKind après avoir renseigné votre propriété DateTime avec la valeur de la base de données.

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

Voir MSDN

Answer 4

Tant que votre couche de services Web et votre couche client utilisent le type .NET DateTime, elle doit être sérialisée et désérialisée correctement en tant que date / heure locale au format SOAP avec des informations de fuseau horaire telles que:

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

Si vous devez absolument connaître le fuseau horaire lui-même (c'est-à-dire qu'il peut s'agir de l'heure normale de l'Est ou de l'heure avancée du Centre), vous devez créer votre propre type de données, qui expose ces éléments en tant que tels:

[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 ressemblerait à:

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

Answer 5

J'ai eu de la chance en conservant simplement le type de données DateTime et en le stockant toujours au format GMT. Dans chaque couche, j'ajusterais la valeur GMT à la valeur locale de la couche.