Dotnet-api-docs: If this method is obsolete, how to replace it with the other overload?

[CeciAc]

@jongleur1983 commented on Mon Jul 01 2019

It's mentioned, that the ToString(DateTime, XmlDateTimeSerializationMode) overload of ToString should be used instead.
But which enum value of XmlDateTimeSerializationMode matches the old behavior? (if any)?

---

Dokumentdetails

⚠ Bearbeiten Sie diesen Abschnitt nicht. Er ist für die Verknüpfung von docs.microsoft.com zum GitHub-Artikel erforderlich.

• ID: 15a194ea-bdb0-e1f2-1b8b-11c2a255732d
• Version Independent ID: 181423b7-1c3a-2a27-023b-4db7550543c7
• Content: XmlConvert.ToString Method (System.Xml)
• Content Source: xml/System.Xml/XmlConvert.xml
• Product: dotnet-api
• Technology: system.xml
• GitHub Login: @dotnet-bot
• Microsoft Alias: dotnetcontent

[CeciAc]

Hi team,
I'm moving this here since the user is making a suggestion to the original documentation
best

[mairaw]

@carlossanlop @tarekgh @GrabYourPitchforks who could help with this feedback for https://docs.microsoft.com/en-us/dotnet/api/system.xml.xmlconvert.tostring?view=netframework-4.8#System_Xml_XmlConvert_ToString_System_DateTime_?

Would it be the same as calling with Unspecified? We could just add that info to the note about the obsolete behavior.

[mairaw]

I'm guessing this area would belong to @buyaa-n @krwq?

[GrabYourPitchforks]

If you're doing this for serialization purposes, I'd recommend the RoundtripKind value. It won't be character-for-character the same as Convert.ToString(DateTime), but that's OK since the point of this overload is to generate a string that has better compatibility across the ecosystem of XML serialization libraries.

FWIW, if possible I'd recommend changing the calling code to use DateTimeOffset instead of DateTime. That's the normal recommendation for applications which are working with "point in time" data and need to preserve timezone information unambiguously.

[tarekgh]

I agree with @GrabYourPitchforks to use RoundtripKind is the best option.

[buyaa-n]

Thank you @GrabYourPitchforks @tarekgh, XmlDateTimeSerializationMode.RoundtripKind seems the closest match with the old behavior

[jongleur1983]

Hi.
As the original poster of that question, my problem back then was to migrate a serialization API, so it was crucial to keep the same format.
The hint on the obsolete method just was "use the other overload", which is not sufficient to know if that's an exact replacement or where the differences are.

Basically it would have been helpful (and would have solved my question beforehand) if there had been a hint on what exact method to call with which parameters to get the same result.

So if there's no exact match that should be mentioned, in ideal case by mentioning the differnces. If there is (perhaps there is a format string that fits, so ToString(DateTime, string) could be used?), it would be good to know what that parameter has to be.

[buyaa-n]

@jongleur1983 thank you for your valuable input, as you mentioned for exact match ToString(DateTime value, string format) could be used, where format value should be "yyyy-MM-ddTHH:mm:ss.fffffffzzzzzz", we will update the doc with suggested XmlDateTimeSerializationMode and the exact replacement option

[tarekgh]

my problem back then was to migrate a serialization API, so it was crucial to keep the same format.

Did you try to deserialize the data which is serialized with ToString(DateTime, XmlDateTimeSerializationMode.RoundtripKind ) and didn't work? ToDateTime(string, XmlDateTimeSerializationMode.RoundtripKind) should work just fine.

[jongleur1983]

@tarekgh I'm not sure how we solved the issue back then.
Maybe we even changed the API on both sides (producer and consumer) to ensure it would work.

I don't care about that issue any more. All I wanted to achieve was something like the additional hint suggested by @buyaa-n .