C # DateTime.ToString con interrupciones zzz en dotnet framework pero no en dotnet core

Question

Tengo mi hora local en GMT +01: 00 como la hora de escribir. Experimento algo, para mí inesperado, cuando hago un ToString de la siguiente manera. Aquí vamos:

Demostrando la configuración del sistema local con la zona horaria +01: 00 (todos estos se ejecutan en verde):

var myLocalDate = new DateTime(2020, 11, 25, 08, 00, 00, DateTimeKind.Local);
Assert.AreEqual("2020-11-25T08:00:00+01:00", myLocalDate.ToString(@"yyyy-MM-dd\THH:mm:sszzz"));
Assert.AreEqual(DateTimeKind.Local, myLocalDate.Kind);
Assert.AreEqual(myLocalDate, myLocalDate.ToLocalTime());

Y ahora creo el mismo tiempo, en utc, restando manualmente una hora y especificando el "utc" como tipo. Pero cuando llamo a ToString, la zona horaria está escrita como +01: 00 que esperaría que fuera +00: 00:

var myUtcDate = new DateTime(2020, 11, 25, 07, 00, 00, DateTimeKind.Utc);
// THIS Breaks:
Assert.AreEqual("2020-11-25T07:00:00+00:00", myUtcDate.ToString(@"yyyy-MM-dd\THH:mm:sszzz"));

Mensaje de error:

Mensaje: Assert.AreEqual falló. Esperado: <2020-11-25T07: 00: 00 + 00: 00>. Real: <2020-11-25T07: 00: 00 + 01: 00>.

¿Extraño algo sobre las fechas y los formatos aquí, o es quizás un error conocido?

Ejecuto .Net Framework 4.8

Esta publicación trata sobre el mismo problema, veo: Cómo resolver el error DateTimeInvalidLocalFormat: "Una fecha y hora UTC se está convirtiendo en texto en un formato que solo es correcto para la hora local".

ACTUALIZAR:

La ejecución del siguiente programa produce diferentes resultados en dotnet framework y dotnet core (como lo menciona evk):

Console.WriteLine(new DateTime(2025, 11, 25, 07, 00, 00, DateTimeKind.Utc).ToString(@"yyyy-MM-dd\THH:mm:sszzz"));

impresiones de dotnet core:

2020-11-25T07: 00: 00 + 00: 00

impresiones del marco dotnet:

2020-11-25T07: 00: 00 + 01: 00

Además, cuando se ejecuta dotnet framework en modo de depuración, aparece el siguiente mensaje del asistente de depuración, pero se ignora internamente en DateTime.ToString ():

Asistente de depuración administrada 'DateTimeInvalidLocalFormat': 'Se está convirtiendo una fecha y hora UTC en texto en un formato que solo es correcto para la hora local. Esto puede suceder cuando se llama a DateTime.ToString utilizando el especificador de formato 'z', que incluirá un desplazamiento de zona horaria local en la salida. En ese caso, use el especificador de formato 'Z', que designa una hora UTC, o use la cadena de formato 'o', que es la forma recomendada de conservar una fecha y hora en el texto. Esto también puede ocurrir cuando se pasa un DateTime para que XmlConvert o DataSet lo serialice. Si usa XmlConvert.ToString, pase XmlDateTimeSerializationMode.RoundtripKind para serializar correctamente. Si usa DataSet, establezca DateTimeMode en el objeto DataColumn en DataSetDateTime.Utc. '

Answer 1

No, se comporta como está documentado. De la documentación del zzzespecificador de formato (el énfasis es mío):

Con DateTimevalores, el especificador de formato personalizado "zzz" representa el desplazamiento firmado de la zona horaria del sistema operativo local con respecto a UTC, medido en horas y minutos. No refleja el valor de la DateTime.Kindpropiedad de una instancia . Por este motivo, no se recomienda el uso del especificador de formato "zzz" con DateTimevalores.

Podría decirse que es lamentable, pero no es un error.

Tenga en cuenta que .NET Core (y .NET 5.0) aparentemente no se comporta como se documenta. Si bien podría argumentar que está "arreglado" en .NET Core, sugeriría que comportarse de manera indocumentada es un error en sí mismo y que podría hacer que la migración de código sea más difícil de lo esperado.

Le sugiero que siga la recomendación en los documentos y evite usar zzzcon DateTimevalores. Yo también sugerir el uso de mi Noda Tiempo biblioteca en lugar, donde no es la ambigüedad en términos de un valor "tal vez por ser locales, o tal vez de ser UTC", pero eso es un poco distinto. (No esperaría que se encontrara con este problema con Noda Time, y con suerte su otro código de fecha / hora sería más claro).