C # DateTime.ToString z przerwami zzz w platformie dotnet, ale nie w rdzeniu dotnet

Question

Mam czas lokalny w GMT +01: 00 jako czas pisania. Doświadczam czegoś nieoczekiwanego, wykonując ToString w następujący sposób. No to ruszamy:

Demonstracja lokalnych ustawień systemu ze strefą czasową +01: 00 (wszystkie są zielone):

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());

A teraz tworzę ten sam czas, w utc, ręcznie odejmując godzinę i określając „utc” jako rodzaj. Ale kiedy dzwonię do ToString, strefa czasowa jest zapisywana jako +01: 00, którą spodziewałbym się +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"));

Komunikat o błędzie:

Komunikat: Assert.AreEqual nie powiodło się. Oczekiwany: <2020-11-25T07: 00: 00 + 00: 00>. Rzeczywiste: <2020-11-25T07: 00: 00 + 01: 00>.

Czy brakuje mi tutaj informacji o czasie i formatach danych, czy może to znany błąd?

Używam .Net Framework 4.8

Ten post dotyczy tego samego problemu, widzę: Jak rozwiązać błąd DateTimeInvalidLocalFormat: „Czas UTC jest konwertowany na tekst w formacie, który jest poprawny tylko dla czasów lokalnych.”?

AKTUALIZACJA:

Uruchomienie następującego programu daje różne wyniki w platformie dotnet i rdzeniu dotnet (jak wspomniano przez evk):

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

wydruki rdzeniowe dotnet:

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

wydruki dotnet Framework:

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

Ponadto podczas uruchamiania platformy dotnet w trybie debugowania pojawia się następujący komunikat asystenta debugowania, ale jest wewnętrznie ignorowany w DateTime.ToString ():

Asystent zarządzanego debugowania „DateTimeInvalidLocalFormat”: „Czas UTC DateTime jest konwertowany na tekst w formacie, który jest poprawny tylko dla czasów lokalnych. Może się to zdarzyć podczas wywoływania DateTime.ToString przy użyciu specyfikatora formatu „z”, który będzie uwzględniał przesunięcie lokalnej strefy czasowej w danych wyjściowych. W takim przypadku użyj specyfikatora formatu „Z”, który określa czas UTC, lub użyj ciągu formatu „o”, który jest zalecanym sposobem na utrwalenie DateTime w tekście. Może to również wystąpić podczas przekazywania DateTime do serializacji przez XmlConvert lub DataSet. Jeśli używasz XmlConvert.ToString, przekaż XmlDateTimeSerializationMode.RoundtripKind, aby poprawnie serializować. W przypadku korzystania z DataSet ustaw DateTimeMode w obiekcie DataColumn na DataSetDateTime.Utc. '

Answer 1

Nie, zachowuje się zgodnie z dokumentacją. Z dokumentacji specyfikatora zzzformatu (wyróżnienie moje):

W przypadku DateTimewartości specyfikator formatu niestandardowego „zzz” reprezentuje podpisane przesunięcie strefy czasowej lokalnego systemu operacyjnego od czasu UTC, mierzone w godzinach i minutach. To nie odzwierciedlać wartość danej instancji DateTime.Kindobiektu . Z tego powodu specyfikator formatu „zzz” nie jest zalecany do używania z DateTimewartościami.

Prawdopodobnie to niefortunne, ale to nie jest błąd.

Należy zauważyć, że .NET Core (i .NET 5,0) najwyraźniej nie zachowują się zgodnie z dokumentacją. Chociaż można by argumentować, że problem został „naprawiony” w .NET Core, sugerowałbym, że zachowanie w nieudokumentowany sposób jest błędem samym w sobie i może utrudnić migrację kodu niż oczekiwano.

Sugeruję, abyś postępował zgodnie z zaleceniami w dokumentacji i unikał używania zzzz DateTimewartościami. Chciałbym również zasugerować używając mojego Noda Czas bibliotekę zamiast tam, gdzie nie jest wieloznaczność pod względem wartości „może być lokalny, czy może być UTC”, ale to już nieco inna sprawa. (Nie spodziewałbym się, że napotkasz ten problem przy użyciu czasu Noda, a Twój inny kod daty / czasu miałby nadzieję, że byłby jaśniejszy.)