[release/10.0] Fix ReadContentAsDateTime method to keep DateTimeKind #119917
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #114969 to release/10.0
/cc @StephenMolloy @BradBarnich
Customer Impact
The DateTimeHelper in System.ServiceModel.Syndication rejects otherwise valid RFC 822 (RSS 2.0–compliant) dates that use a single digit day (e.g., “7 Jun 2023”) or certain two digit year patterns due to an incomplete and partially incorrect format array passed to DateTimeOffset.TryParseExact. (RFC 822 is an older, but still valid spec.) The fix augments and corrects the accepted date format strings to allow 1–2 digit days and properly handle intended two digit year forms, without changing any other parsing behavior.
Regression
This was introduced in 7.0 when we brought the internals of DataContractSerializer in line with the 4.8 implementation. (Previously, DCS was cobbled together from a partial implementation pulled from it's Silverlight port.)
Testing
PR for added test is here
Risk
This is a low risk, localized change confined to expanding the format list in a private helper.
IMPORTANT: If this backport is for a servicing release, please verify that:
release/X.0-staging
, notrelease/X.0
.Package authoring no longer needed in .NET 9
IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.