Ich arbeite daran, einen Bug in einer großen Codebasis zu bereinigen, wo niemand auf lokale Zeit und UTC-Zeit geachtet hat.
Was wir wollen, ist eine Möglichkeit, die Zeitzoneninformationen von DateTime-Objekten, die von und zu unseren ASP.NET-Webdiensten gesendet werden, global zu ignorieren. Ich habe eine Lösung für Abrufvorgänge. Daten werden nur in Datasets zurückgegeben, und ich kann nach DateTime-Spalten suchen und den DateTimeMode auf Nicht angegeben einstellen. Das löst mein Problem für alle Daten innerhalb eines Datensatzes hin und her.
Allerdings werden DateTime-Objekte oft auch direkt als Parameter an die Webmethoden übergeben. Ich möchte alle eingehenden Zeitzoneninformationen entfernen. Anstatt unseren Clientcode zu durchsuchen und DateTime.SpecifyKind (..) zu verwenden, um alle DateTime-Variablen auf Undefined zu setzen, möchte ich eine Art globale ASP.NET-Überschreibung ausführen, um eingehende Parameter zu überwachen und die Zeitzoneninformationen auszublenden.
Ist so etwas möglich? Oder gibt es einen anderen einfacheren Weg zu tun, was ich tun möchte?
Nur um es noch einmal zu wiederholen: Ich interessiere mich nicht für Zeitzonen, alle sind in der gleichen Zeitzone. Aber ein paar Benutzer haben Maschinen schlecht konfiguriert, falsche Zeitzonen, usw. Also, wenn sie senden in 1. Juli 2008, bekomme ich 30. Juni 2008 22:00:00 auf der Serverseite, wo es automatisch von ihrem konvertiert lokale Zeit für die lokale Zeit des Servers.
Update: Eine andere Möglichkeit wäre, wenn es möglich wäre, eine Änderung am clientseitigen .NET-Code vorzunehmen, um die Art und Weise zu ändern, in der DateTime-Objekte mit Kind 'Undefined' serialisiert werden.
Ich habe das oft in vielen Anwendungen, Diensten und auf verschiedenen Plattformen (.NET, Java usw.) behandelt. Bitte glauben Sie mir, dass Sie NICHT die langfristigen Konsequenzen davon haben wollen, dass Sie sich nicht um die Zeitzone kümmern. Nachdem Sie viele Fehler verfolgt haben, die enorm schwierig und teuer zu beheben sind, werden Sie sich wünschen, dass Sie sich darum gekümmert haben.
Anstatt also die Zeitzone zu entfernen, sollten Sie entweder die richtige Zeitzone erfassen oder eine bestimmte Zeitzone erzwingen. Wenn Sie es vernünftigerweise können, sollten Sie die verschiedenen Datenquellen korrigieren, um eine korrekte Zeitzone bereitzustellen. Wenn sie nicht in Ihrer Kontrolle sind, erzwingen Sie sie entweder in der lokalen Zeitzone des Servers oder in UTC.
Die allgemeine Industriekonvention besteht darin, alles auf UTC zu setzen und alle Uhren der Produktionshardware auf UTC zu setzen (dh Server, Netzwerkgeräte wie Router usw.). Dann sollten Sie in der Benutzeroberfläche auf die lokale Zeitzone des Benutzers übersetzen.
Wenn Sie es jetzt richtig beheben, kann es einfach und billig sein. Wenn du es absichtlich weiter brichst, weil du denkst, dass es billiger wird, dann wirst du später keine Entschuldigungen haben, wenn du das schreckliche Durcheinander entwirren musst.
Beachten Sie, dass dies dem allgemeinen Problem mit Strings ähnelt: Es gibt keinen einfachen Text (ein String ohne Zeichencodierung) und es gibt keine einfache Zeitzone (keine Zeitzone). So etwas vorzugeben ist die Quelle von viel Schmerz und Herzschmerz und peinlichen Fehlern.
OK, ich habe einen Workaround dafür, der davon abhängt, dass ich nur den Date-Teil der DateTime brauche. Ich füge diese Eigenschaft jedem Datum oder DateTime-Parameter im System
bei %Vor%Dies ändert die generierte WSDL so, dass sie den Typ s: date anstelle von s: dateTime hat. (Beachten Sie, dass der Typ des .NET-Methodenparameters einfach ein Date anstelle einer DateTime ist, was dies NICHT bewirkt). Der Client sendet nun nur noch den Datumsteil der DateTime, keine Zeitinfo, keine Zeitzoneninfo.
Wenn ich jemals einen Datums- und Uhrzeitwert an den Server senden muss, muss ich eine andere Problemumgehung verwenden, wie zum Beispiel einen String-Parameter.
Ich hatte auch Probleme mit der Zeitzoneninformation. Das Problem ist, dass ich die Datetime-Felder bereits in UTC zur Verfügung stelle. Dann findet die Serialisierung statt und der lokale Offset wird Teil des Datums / der Zeit. Die Daten für unseren Anbieter in einer anderen Zeitzone waren ziemlich durcheinander. Ich habe dieses Problem umgehen können, indem ich die Tsql-Konvertierungsfunktion für die Datetime-Felder in meiner Select-Anweisung verwendete, die ich zum Füllen meiner Datasets verwendete. Dadurch wurden die Felder in eine Zeichenfolgenvariable konvertiert, die auf der Clientseite automatisch in einen datetime-Wert umgewandelt wird. Wenn Sie nur das Datum übergeben möchten, können Sie den 101-Code verwenden, um nur das Datum anzugeben. Ich habe 126 verwendet, um das Datum und die Uhrzeit genau so anzugeben, wie es in meinen Datenbankspalten erscheint, wobei die Zeitzoneninformationen entfernt sind.
Tags und Links asp.net web-services