Prévenir le fuseau horaire de conversion sur la désérialisation de valeur DateTime

J'ai une classe que je sérialiser/désérialiser l'aide de XmlSerializer. Cette classe contient une DateTime champ.

Quand sérialisé, le DateTime champ est représenté par une chaîne qui comprend le décalage par rapport à GMT, l'e.g 2010-05-05T09:13:45-05:00. Lorsque désérialisé, ces temps sont convertis à l'heure locale de la machine effectuant la désérialisation.

Pour des raisons pas la peine de lui expliquer, j'aimerais éviter ce fuseau horaire de conversion de passe. La sérialisation qui se passe dans la nature, où plusieurs version de cette classe existe. La désérialisation se produit sur un serveur qui est sous mon contrôle. En tant que tel, il semble que cela devrait être mieux traité lors de la désérialisation.

Comment puis-je faire ceci se produire, autre que la mise en œuvre de IXmlSerializable et de faire tout de la désérialisation "à la main?"

  • Quelqu'un peut-il me donner un lien sur l'exacte vice versa de cette question? (En passant DateTime de .Net serveur à client JavaScript)
InformationsquelleAutor Odrade | 2010-07-06
  1. 24

    Au lieu de l'analyse comme une DateTime vous pouvez l'analyser comme un DateTimeOffset et l'utilisation de la DateTimeOffset.DateTime propriété d'ignorer le fuseau horaire. Comme ceci:

    [XmlIgnore()]
public DateTime Time { get; set; }

[XmlElement(ElementName = "Time")]
public string XmlTime
{
    get { return XmlConvert.ToString(Time, XmlDateTimeSerializationMode.RoundtripKind); }
    set { Time = DateTimeOffset.Parse(value).DateTime; }
}
    • Aussi, parce que je suis en utilisant entity framework, j'ai dû mettre [NotMapped] en plus de la [XmlElement...] mais cette solution fonctionne parfaitement pour moi. merci
    InformationsquelleAutor Adam Hughes
  2. 29

    Ce que j'ai fait, c'était pour utiliser DateTime.SpecifyKind méthode, comme suit: 

    DateTime dateTime = DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified);

    Et ce pour résoudre mon problème, j'espère que cela vous aidera.

    InformationsquelleAutor Arvi
  3. 2

    Pourriez-vous essayer quelque chose comme cette post suggère et en faire une nouvelle chaîne de propriété et XmlIgnore l'existant:

    Mettre [XmlIgnore] sur la propriété de Temps.

    Puis ajouter une nouvelle propriété:

    [XmlElement(DataType="string",ElementName="Time")]
public String TimeString
{
   get { return this.timeField.ToString("yyyy-MM-dd"); }
   set { this.timeField = DateTime.ParseExact(value, "yyyy-MM-dd", CultureInfo.InvariantCulture); }
}
    • J'ai besoin de désérialiser les anciennes versions de la classe à l'aide de la version mise à jour. Ne pas ce casser la compatibilité? Je peux renommer mon DateTime propriété et ajouter une propriété de type chaîne qui a le même nom que le DateTime utilisé pour. Mais, cela permettra de briser les clients qui font référence à la date de la propriété.
    • Oh, je vois maintenant que le nom de l'Élément restera le même dans le Xml. Laissez-moi essayer.
    • Ce code ne fonctionnera pas avec vos clients existants, car le DateTime.ParseExact échoue (car le temps n'est pas dans ce format). Si vous analyser comme un DateTimeOffset au lieu de cela, il travaillera avec vos clients existants.
    • J'ai adapté cette approche de ma situation (supprimer le décalage UTC quand il est là, ensuite d'analyser). Votre approche n'a pas l'air plus propre, cependant.
    InformationsquelleAutor SwDevMan81
  4. 2

    Je sais que c'est vieux, mais espérons que cela aide quelqu'un dans le futur.

    Voici le XML, j'ai été désérialisation:

    <timePeriod>1982-03-31T00:00:00+11:00</t

    Après la désérialisation XML, je me retrouve avec la 30 pas de la 31e:

    Prévenir le fuseau horaire de conversion sur la désérialisation de valeur DateTime

    Il semble que la 3ème partie qui produisent ce XML (que j'utilise) changer le Fuseau horaire de +11 au cours de l'heure d'été et de le garder aussi +10 quand ce n'est pas l'heure d'été (DST).

    Selon Jon Skeet UTC ne devriez pas envisager de l'heure d'été: https://stackoverflow.com/a/5495816/495455

    Notez également la documentation Le codage des Meilleures Pratiques à l'Aide de DateTime dans la .NET Framework:


    Le sérialiseur XML suppose toujours que les valeurs DateTime être sérialisé représenter la section locale de la machine du temps, de sorte qu'il s'applique à la machine locale, décalage horaire le décalage partie de l'encodage XML de temps. Lorsque nous désérialiser ce sur une autre machine, le décalage d'origine est soustraite de la valeur analysée, et la machine actuelle est le décalage de fuseau horaire est ajouté.

    Le code suivant m'a permis d'obtenir la date au format le 31, mais il l'habitude de travailler à 100% pour les non Daylioght Économie dates (donné dans ce fil):

    TimeZoneInfo easternZone = TimeZoneInfo.FindSystemTimeZoneById("AUS Eastern Standard Time");
DateTime easternTimeNow = TimeZoneInfo.ConvertTimeFromUtc(dataPoint.timePeriod, easternZone);
System.Diagnostics.Debug.WriteLine(easternTimeNow.ToString());

    Donc la solution est de fixer le flux XML n'a donc pas d'alternative UTC avec l'heure d'été.

    EDIT: pourquoi les données ont été foiré

    Il s'avère que ce n'est PAS le 3ème fournisseur tiers évolution de l'UTC à l'heure d'été. Le flux XML est créé par Java Swing cadre de la lecture d'un SQL dB. Normalement, je devrais vous recommandons de le conserver avec la norme XML de représentation (xsd:dateTime) – IS0 8601, mais dans ce cas, l'aide de la chaîne et l'extraction de tout ce qui est après le T travaux. Avertissement, je suis encore à essayer d'obtenir l'alimentation a changé, vous recommandons de ne PAS le faire en PROD. Utilisez à votre propre risque!!

    InformationsquelleAutor Jeremy Thompson