Laden...

Datumsformat in Webanwendungen wird nach Serverwechsel in Englisch angezeigt

Erstellt von Cord Worthmann vor einem Jahr Letzter Beitrag vor einem Jahr 620 Views
C
Cord Worthmann Themenstarter:in
1.215 Beiträge seit 2004
vor einem Jahr
Datumsformat in Webanwendungen wird nach Serverwechsel in Englisch angezeigt

Moin-moin!

Wir haben gestern einen Serverumzug vorgenommen. Das neue System (Win Server 2022) lag dabei in Englisch vor und hatte zunächst auch eine falsche Zeitzone (UTC-7, Pacific Time), obwohl der Server in Frankfurt stehen soll.

Auf dem System wurde u.a. das NETv7.0.5 Hosting Bundle installiert, und alle migrierten Apps liefen auch einwandfrei. Allerdings wird bei mehreren Anwendungen jetzt das Englische Datumsformat ausgegegeben, wenn dieses per DateTime.ToString erzeugt wurde.

Wir haben verschiedene Dinge ausprobiert, um dieses Verhalten abzustellen, z.B. Deutsch auf Systemebene als Sprache eingerichtet, NET-Framework neu installiert... aber das Datumsformat bleibt Englisch.

Jetzt in allen Anwendungen den Code oder die Culture anzupassen kann die Lösung IMO nicht sein. Weiß hier zufällig jemand Rat, was zu tun ist, um ASP.NET die Englische Schreibweise auszutreiben?

Bin über jede Anregung dankbar

Grüße

16.861 Beiträge seit 2008
vor einem Jahr

Server sollten immer nach UTC eingestellt sein und die Anwendung ist verantwortlich das in die Zeitzone des Besuchers anzupassen.
Dafür gibts DateTimeOffset mit den entsprechenden Cultures.

[FAQ] DateTime vs. DateTimeOffset und der Umgang mit Zeiten in .NET
Manuell anzupassen - aber nicht zu empfehlen - in allen .NET Runtimes über die Thread.Culture - inkl. potentiellen Nebenwirkungen.
Der einzig korrekte Weg ist die Angabe der Parameter, weil nur das auch mit externen Libs etc skaliert.

C
Cord Worthmann Themenstarter:in
1.215 Beiträge seit 2004
vor einem Jahr

Das hilft mir leider nicht weiter, denn es geht nicht um den Offset, sondern um das Datums/Zeitformat, das eben nicht in Englisch (05/26/2022 02:55 PM), sondern in Deutsch (26.05.2022 14:55) ausgegeben werden soll. Und da die Ausgabe auf dem alten Server wie beabsichtigt funktionierte, muss es sich hier um eine globale, systemabhängige Einstellung handeln, die wir gerne ändern wollen, wenn wir denn wüssten, was zu tun ist.

16.861 Beiträge seit 2008
vor einem Jahr

Ist mir schon klar - aber DateTimeOffset hilft Dir a) beim sicheren Anpassen der Zeitzone und b) bei der Formatierung durch die entsprechenden Parameter.

Default-Format ergibt sich immer aus der Thread.Culture, wenn nichts angegeben wird.
Daher hab ichs Dir geschickt.

C
Cord Worthmann Themenstarter:in
1.215 Beiträge seit 2004
vor einem Jahr

Ich verstehe. Allerdings wollen wir ja gerade den Code nicht ändern, weil das Ausgabeformat auf dem alten Server korrekt war, und wir jetzt davon ausgehen, dass irgendeine Windows-seitige Andersartigkeit für das falsche Datumsformat verantwortlich ist, die man eigentlich abstellen können müsste. Zeitzone, Systemzeit u. Standardsprache wurden inzwischen per Powershell auf UTC+2 u. Deutsch festgelegt. Festlegen der Culture per web.config hat auch nichts gebracht.

Ich meine, wenn ein und derselbe Code zuvor wie beabsichtigt ausgegeben wurde und auf dem neuen System nicht, dann muss das Problem doch auf Server-Ebene behebbar sein und nicht (nur) per Code-Anpassung.

16.861 Beiträge seit 2008
vor einem Jahr

Okay, dann gern nochmal ganz von vorn:

  • Alle Format-Angaben sollten mit Parameter verwendet werden; wird kein Parameter angeben, dann wird die Thread Culture verwendet
  • Die Thread-Culture kannst Du aktiv setzen; setzt Du sie aktiv nicht, dann wird die Betriebssystem-Culture verwendet. Wird Deine app.config Setting nicht übernommen, dann hast was falsch gemacht.
  • Die Betriebssystem-Culture unter Windows ist die Regionseinstellung - nicht die Sprache
  • Die Regionseinstellung hat angaben für Formate, Währungen und Co

Change the Windows regional settings to modify the appearance of some data types

Die Trennung von Sprache und Region gilt für jede Art von Lokalisierung und für jede Runtime. Ansonsten wären Standards wie "en-us" oder "de-de" bzw "de-at" nicht möglich.

J
641 Beiträge seit 2007
vor einem Jahr

Vlt. hilft das: https://serverfault.com/questions/980215/asp-net-core-site-has-the-wrong-default-culture-when-run-with-iis

cSharp Projekte : https://github.com/jogibear9988

C
Cord Worthmann Themenstarter:in
1.215 Beiträge seit 2004
vor einem Jahr

Die Lösung war jetzt folgende:

Als AppPools u. Websites eingerichtet wurden, war der Server noch auf en-US konfiguriert, und diese Einstellungen haben die AppPools übernommen, so dass die jeweilige Culture aus den AppPool-Settings kam. Offenbar haben die Vorrang vor globalen Einstellungen in der web.config.

Es wurden nun einfach neue AppPools angelegt, die de-DE verwenden, und damit stimmen auch die Datumsformate wieder.

Trotzdem vielen Dank für die Ratschläge!