Skip to content

Fix DateTimeOffset deserialization in IXmlSerializable context #119030

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Copilot
Copy link
Contributor

@Copilot Copilot AI commented Aug 23, 2025

This fixes a regression introduced in .NET 7.0+ where DateTimeOffset values were incorrectly deserialized when DataContractSerializer was used within IXmlSerializable.ReadXml() methods.

Problem

When deserializing DateTimeOffset in nested serialization scenarios, the UTC time component was being treated as local time instead of UTC time, causing incorrect results:

// Original: 04/17/2025 22:45:00 -04:00
// Incorrect result: 04/18/2025 02:45:00 -04:00 (4 hours off!)

public class Container : IXmlSerializable
{
    public TestObject TestObject { get; set; }
    
    public void ReadXml(XmlReader reader)
    {
        var serializer = new DataContractSerializer(typeof(TestObject));
        reader.ReadStartElement();
        TestObject = (TestObject)serializer.ReadObject(reader); // Problem here
        reader.ReadEndElement();
    }
}

[DataContract]
public class TestObject
{
    [DataMember]
    public DateTimeOffset Date { get; set; }
}

This affected applications upgrading from .NET Framework/.NET 6.0 to .NET 7.0+, particularly CoreWCF applications.

Root Cause

In nested DataContractSerializer scenarios, the XML parsing context causes the DateTime.Kind property to become Unspecified instead of Utc. The DateTimeOffsetAdapter.GetDateTimeOffset() method incorrectly handled this case by treating the datetime as local time in the target timezone, when it should treat it as UTC time (matching the semantic meaning of the UtcDateTime field).

Solution

Modified the DateTimeKind.Unspecified case in DateTimeOffsetAdapter.GetDateTimeOffset() to:

  1. Treat the stored datetime as UTC time regardless of its Kind property
  2. Create a DateTimeOffset from UTC and convert to the target offset
  3. Match the behavior of the DateTimeKind.Utc case

Added a comprehensive regression test DCS_DateTimeOffsetInIXmlSerializableContainer to prevent future regressions.

Verification

  • ✅ All existing DateTimeOffset serialization tests continue to pass (6/6)
  • ✅ New regression test passes
  • ✅ Fix handles the specific IXmlSerializable nested serialization scenario
  • ✅ No breaking changes to existing functionality

Fixes #114813.


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

…dling Unspecified Kind as UTC

Co-authored-by: StephenMolloy <19562826+StephenMolloy@users.noreply.github.com>
@Copilot Copilot AI changed the title [WIP] incorrect DateTimeOffset with DataContractSerializer and IXmlSerializable Fix DateTimeOffset deserialization in IXmlSerializable context Aug 23, 2025
@Copilot Copilot AI requested a review from StephenMolloy August 23, 2025 05:43
Copilot finished work on behalf of StephenMolloy August 23, 2025 05:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

incorrect DateTimeOffset with DataContractSerializer and IXmlSerializable
2 participants