Runtime: `System.Xml.Serialization.XmlSerializer` does silently ignore `System.DatetimeOffset` values

[Bonuspunkt]

example code

public class DatetTimeOffsetContainer
{
    public DateTimeOffset DateTimeOffset { get; set; }
}

public void Test()
{
    var serializer = new XmlSerializer(typeof(DatetTimeOffsetContainer));

    var expected = new DatetTimeOffsetContainer
    {
        DateTimeOffset = new DateTimeOffset(2018, 1, 1, 0, 0, 0, TimeSpan.Zero)
    };

    var stream = new MemoryStream();
    serializer.Serialize(stream, expected);

    stream.Position = 0;

    var actual = (DatetTimeOffsetContainer) serializer.Deserialize(stream);

    Debug.Assert(expected.DateTimeOffset == actual.DateTimeOffset);
    // actual.DateTimeOffset == default(DateTimeOffset)
}

stream content

<?xml version="1.0"?>
<DatetTimeOffsetContainer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <DateTimeOffset />
</DatetTimeOffsetContainer>

expected behavior: data does not disappear

[huanwu]

@yujayee Could you see if it repro on full framework?

[jiayi11]

It can repro on full framework, the DateTimeOffset value is silently ignored.

[drewfreyling]

This sounds like a pretty major bug, I'm astounded it was marked as "Future"

[aarondglover]

Just hit this bug tonight.

Serializing a ValueTuple which contains a DateTimeOffset and it is silently ignored!

[StephenBonikowsky]

There is a workaround for this problem, see the full discussion on stackoverflow ...

[XmlElement("lastUpdatedTime")]
public string lastUpdatedTimeForXml // format: 2011-11-11T15:05:46.4733406+01:00
{
   get { return lastUpdatedTime.ToString("o"); } // o = yyyy-MM-ddTHH:mm:ss.fffffffzzz
   set { lastUpdatedTime = DateTimeOffset.Parse(value); } 
}
[XmlIgnore] 
public DateTimeOffset lastUpdatedTime;

This is definitely a bug we would like to fix, the fact that it also exists on the full framework complicates matters a bit since it is now much more difficulty to get bug fixes approved for full framework post 4.8. (See Scott's blog)

The "Future" milestone simply means we can't consider it for the current 3.0 release.

[StephenBonikowsky]

Moving into next release (5.0)

[drewfreyling]

Is there any chance of just fixing it in core and not framework for now?

[StephenBonikowsky]

The fix will be done in Core for sure, it's too late to get into the 3.0 release so for now it is going into our next big planned release which is 5.0.

It could possibly go into a 3.0 servicing release but we don't know yet if that is possible since 3.0 is not yet out the door.

[drewfreyling]

@StephenBonikowsky now that 3.0 is out the door, what is the likelihood of it being fixed in a servicing release?

[StephenBonikowsky]

@drewfreyling Because it has a workaround we are targeting this for one of the upcoming 5.0 preview releases. So it won't be fixed in the servicing branch.