2

I have set the short date format to "dd/MM/yyyy" in the currentCulture and currentUICulture. However when I try to serialize the object having date time attribute, it still serialize object into xml in "MM/dd/yyyy" format (which is the default format in my machine). Code:

 public static string SerializeObject(this object data)
 {
       var serializer = new DataContractSerializer(data.GetType());
       var output = new StringWriter();

       using (var writer = new XmlTextWriter(output) { Formatting = Formatting.Indented })
       {
            serializer.WriteObject(writer, data);
       }
       return output.GetStringBuilder().ToString();
}

My object structure looks like this

[Serializable]
Class MyClass
{
     DateTime? ProcessDate {get; set;}
}

Instance of MyClass has the ProcessDate value formatted in the short date format specified in the current thread. when I deserialize it takes the short date format mentioned in Current thread's culture.

how to serialize with specific datetime format mentioned in the current thread culture and not by date time format specified at machine level.

user824910
  • 1,067
  • 6
  • 16
  • 38
  • 1
    This [answer](http://stackoverflow.com/a/27860910/3581917) to a similar question might help. – Evil Dog Pie Apr 05 '17 at 08:25
  • This seems to be useful. however I was wondering why the serialization always takes the date format defined on the machine instead of current thread. any idea? – user824910 Apr 05 '17 at 09:57
  • I'm really not sure about that, but I suspect it may be to do with the localization context applicable when SGEN.EXE is run: so it's the machine that does the build, and not even the one running the application. However, I don't know that for certain, and I'm not sure how I'd go about proving it. – Evil Dog Pie Apr 05 '17 at 10:03
  • 2
    Hard to make sense of this question. The point of good serialization is that it will de-serialize reliably anywhere in the world. That of course cannot work well if DataContractSerializer would pay any attention to your machine's or thread's date format selection. XML has a standardized date format, set by ISO 8601. – Hans Passant Apr 05 '17 at 10:58
  • 1
    Microsoft's XML serializers use the ISO 8601 format for dates because it is the standard format specified in [XML Schema Part 2: Datatypes](https://www.w3.org/TR/xmlschema-2/#isoformats). If you want a nonstandard format you will need to use a surrogate property as shown [here](https://stackoverflow.com/a/3534625/3744182). That answer is for `XmlSerializer` so use the the appropriate [data contract attributes](https://msdn.microsoft.com/en-us/library/ms733811(v=vs.110).aspx) instead. – dbc Apr 05 '17 at 16:38
  • @HansPassant @dbc That's interesting, because the O/P indicates that the date is being serialized as `MM/dd/yyyy`, which does not conform to the ISO 8601 (and XML) short date format `yyyy-MM-dd`. Why might that be? – Evil Dog Pie Apr 06 '17 at 15:59
  • @HansPassant It is observed that the serialization and deserialization is on the Invariant culture. Since the instance of MyClass on executed by a thread which does not have invariant culture on it and the datetime format is "dd/MM/yyyy" the conversion to object data on deserialization results in null value for it. I tried to set the current thread with Invariant culture before deserialization and after deserialization I set it back to the my required culture which works. not sure if this is the right approach other than WCF extension methods suggested by mike – user824910 Apr 07 '17 at 07:16
  • I can't reproduce the problem. When I serialize your sample class I see the following element: `<_x003C_ProcessDate_x003E_k__BackingField>2017-05-05T00:00:00-04:00`. The date is serialized in ISO 8601 format. (`__BackingField` appears in the element name because the class is marked as `[Serializable]` as explained [here](https://stackoverflow.com/a/31498951/3744182).) – dbc May 05 '17 at 23:19
  • There is a special place in hell reserved for anyone not serializing in invariant culture. Unfortunately that place is rather crowded... – Guran Jun 14 '17 at 07:46

0 Answers0