Ich habe ein Objekt, das momentan Eigenschaften als DateTime hat.
Das Objekt wird innerhalb eines Zeitrahmens als gültig markiert. Der Standardwert ist 00:00:00 bis 23:59:59
Der Benutzer gibt den Wert in der Benutzeroberfläche ein und die Eigenschaft wird über:
festgelegt %Vor%Dies wird dann in UTC konvertiert, wenn es die Datenbank trifft.
Das heutige Datum ist der 29. August 2013. Wenn ein Kollege in Indien dieses Programm ausführt, wird es die Daten in der Datenbank als 28. August 2013 18:30:00 speichern, da sie 5.5 Stunden vor UTC sind, also 29. August 2013 00:00 : 00 wird gestern.
Wenn die Logik versucht festzustellen, ob das Objekt gültig ist, lautet die Logik:
%Vor%Wir versuchen festzustellen, ob die aktuelle Zeit in einem Bereich von 00:00:00 und 23:59:59
liegtDies schlägt fehl, da 14:00 (aktuelle Zeit) nicht größer als 18:30 ist
Was wäre der beste Ansatz, um einfach mal zu vergleichen?
Würden die Werte als DateTimeOffSet-Hilfe gespeichert, verwendet ToLocal () ok?
Andere Überlegungen sind, dass ein Benutzer in Indien die App verwendet, die in Großbritannien gehostet wird, so dass es zeitzonenabhängig sein muss.
Danke
Wie andere, bin ich immer noch unklar, was genau du willst. Aber klar, du solltest das nicht tun:
%Vor%Das wäre viel besser als:
%Vor%Aber warum tust du das am Anfang? Bei beiden wird das lokale Datum zurückgegeben. Ich gehe davon aus, dass dies auf einem Server ausgeführt wird. Möchten Sie wirklich, dass die Zeitzone des Servers dieses Ergebnis beeinflusst? Wahrscheinlich nicht. Bitte lesen Sie: Der Fall gegen DateTime.Now .
Wenn Sie das UTC-Datum haben wollten, könnten Sie das tun:
%Vor%Das wäre zumindest unabhängig von der Zeitzone Ihres Servers immer gleich. Aber trotzdem, ich glaube nicht, dass Sie danach streben.
Was nicht klar ist, ist warum der Benutzer nur die Zeit eingibt, während Sie das aktuelle Datum zuweisen. Wenn das Datum relevant ist, sollte der Benutzer es nicht eingeben und es wäre Teil Ihres Modells?
Wenn das Datum nicht relevant ist, warum speichern Sie es? Sie können intern den Wert TimeSpan für den Zeitwert verwenden. Sie haben nicht gesagt, was Ihre Datenbank ist, aber lassen Sie uns einfach raten, dass es sich um SQL Server handelt. In diesem Fall könnten Sie den Typ time für das Feld in der Tabelle verwenden.
Ich nehme an, dass es möglich ist, dass das Datum relevant ist, aber Sie es steuern möchten, während der Benutzer Kontrolle über die Bereitstellung der Zeit übernimmt. Wenn dies der Fall ist, müssen Sie die Zeitzone des Benutzers kennen (oder die Zeitzone des jeweiligen Kontexts, wenn es sich nicht um den Benutzer handelt). Angenommen, Sie hatten eine Windows-Zeitzonen-ID (siehe das Zeitzonen-Tag-Wiki ), dann könnten Sie Folgendes tun:
%Vor%Wenn Sie nicht über die Zeitzoneninformationen verfügen, ist dies nicht möglich.
Als generellen Ratschlag solltest du versuchen, Noda Time anstatt des eingebauten Materials zu verwenden. Es ist viel besser, Ihnen zu helfen, diese Art von Dingen herauszufinden. Von der Hauptseite:
Noda Time ist eine alternative Datums- und Zeit-API für .NET. Es hilft Ihnen, klarer über Ihre Daten nachzudenken und Operationen mit diesen Daten genauer auszudrücken.
Das scheint direkt das Problem zu sein, das Sie hier haben. Wenn Sie einige der Fragen klären möchten, die ich gestellt habe, würde ich gerne meine Antwort bearbeiten und Ihnen genau zeigen, wie Sie dies mit Noda Time tun können.
Wir versuchen festzustellen, ob die aktuelle Zeit in einem Bereich von 00:00:00 und 23:59:59
liegt
Alle -Zeiten liegen innerhalb dieses Bereichs. Nun, vielleicht wäre ein Wert wie 23:59:59.1 außerhalb davon, aber Sie sammeln keine Bruchsekunden in Ihrem Modell, das ist also irrelevant. Aber warum sollten Sie das bestätigen? Vielleicht versuchen Sie nur Zahlen zu vermeiden, die gar keine gültigen Zeiten sind? Wie 99:99:99 ?
Dies schlägt fehl, da 14:00 (aktuelle Zeit) nicht größer als 18:30 ist
Warte - du hast nichts über einen Vergleich gesagt, der größer ist als der andere. 14:00 und 18:30 sind immer noch in dem Bereich, den Sie angegeben haben.
Was wäre der beste Ansatz, um einfach mal zu vergleichen?
Schwer zu beantworten. Sind sie beide UTC-Zeiten? Ist eine UTC und eine lokale? Sind sie beide lokal? Kennst du die Zeitzone der lokalen Zeiten? Sind Sie bereit, mit mehrdeutigen oder ungültigen Ortszeiten für Sommerzeitübergänge umzugehen?
Würden die Werte als DateTimeOffSet-Hilfe gespeichert?
Vielleicht, aber Sie haben mir nicht genug Informationen gegeben. Es würde nur helfen, wenn der Datumsbereich relevant ist und Sie die richtigen Offsets erhalten.
verwendet ToLocal () ok?
Ich würde behaupten, nein, es ist nicht in Ordnung. Local gibt in diesem Zusammenhang die Zeitzone des Servers an, die Sie wahrscheinlich nicht in Ihre Geschäftslogik einführen möchten.
Wenn ich das also richtig verstehe, haben Sie eine Zeit in UTC in der Datenbank gespeichert und versuchen zu bestimmen, ob sie in einen bestimmten Zeitrahmen fällt? Ich bin mir nicht sicher, ob Sie den Zeitrahmen in Ortszeit oder UTC möchten, also hier sind beide:
%Vor%Bearbeiten: Wenn Sie Now mit einer Start- und Endzeit von einem Objekt in der Datenbank vergleichen möchten:
%Vor%Ich würde sagen, dass die hier angewandte Methode grundlegend fehlerhaft ist und dass Sie einen anderen Ansatz verfolgen müssen.
%Vor%Ich sehe keine Möglichkeit, die Eingabe auf diese Weise zu "normalisieren", es sei denn, Sie haben eine zuverlässige Möglichkeit, genau zu wissen, in welcher Zeitzone sich ein Benutzer gerade befindet. Es gibt keinen einfachen Weg, ein so erstelltes Datum zu drehen in UTC.
Meine erste Frage an Sie ist, wie wird das Modell von Client zu Server übertragen? Wenn Sie javascript / ajax verwenden, sollte die Lösung ziemlich einfach zu lösen sein, indem Sie das datetime-Objekt auf dem Client erstellen (das ihre Zeitzonendaten enthält) und dann den Browser für die Konvertierung in UTC verwenden.
>Wenn Sie Razor \ MVC verwenden, können Sie eine ähnliche Sache mit der Formularcodierung erreichen, außer dass Sie ToUTC auf dem Server aufrufen müssen, da der Browser das Datum für dieses Medienformat nicht automatisch festlegt.
Beide Methoden erfordern, dass Sie auf dem Client ein vollständiges Datetime-Objekt erstellen und es dann senden, anstatt zu versuchen, es aus Sekunden, Minuten, Stunden auf dem Server zu erstellen. Sie müssen dies natürlich dem Kunden nicht offen legen, solange die Datetime zum Zeitpunkt der Einreichung vollständig ist.
Sobald Sie eine schöne UTC-Datetime haben, können Sie nur die Zeit extrahieren, wenn Sie den Rest nicht brauchen.
Hoffe, das hilft.
Pete