Entschuldigung, wenn das eine einfache Frage zu sein scheint, aber ich möchte nur überprüfen, ob die Lösung, die ich habe, für alle Fälle am sinnvollsten ist.
Die vorhandene SQL Server-Datenbank, mit der wir arbeiten, speichert einen 'Punkt' als inklusive Start - & gt; inklusive Ende UTC DateTime Werte. (Beide Start- und Endspalten sind datetime2(7) , werden automatisch in System.DateTime Instanzen von DateTimeKind.UTC konvertiert, bevor wir mit ihnen arbeiten).
Also, wenn ich den "ganzen Tag / Monat / Jahr, Zeitzone des Benutzers speichern muss" muss ich finden "Der letzte mögliche Zeitpunkt eines bestimmten LocalDate, in einer bestimmten DateTimeZone" .
Die Methoden, die ich habe, sind wie folgt:
%Vor% Ich denke, ich muss auch vermeiden, dass irgendwo anders ein "Ende des Datums" abgebildet wird LocalDateTime mit .AtLeniently(..) , da wenn 23: 59: 59.9999999 "übersprungen" wird und nicht im Ziel DateTimeZone existiert, dann würde es auf den nächsten verfügbaren Zeitpunkt auf der "äußeren" Seite der Lücke 00: 00: 00.000000 gemappt werden, was mir einen exklusiven ZonedDateTime -Wert geben würde.
Geänderte Methoden:
%Vor%Erstens, wie in Kommentaren erwähnt, ist es immer eine gute Idee, wenn Sie mit einer exklusiven oberen Grenze arbeiten können:
Ihre AtEndOfDay -Methode erscheint mir vernünftig, außer dass ich Duration.Epsilon anstelle von Duration.FromTicks verwenden würde. Insbesondere werden wir uns in Noda Time 2.0 auf eine Genauigkeit von Nanosekunden anstelle von Ticks bewegen; Duration.Epsilon wird in beiden Fällen tun, was Sie wollen.
Für Ihre LocalDate -Lösung scheint mir ein Wert von LocalTime.MaxValue (oder EndOfDay ), der größten darstellbaren LocalTime , zu fehlen. Wenn das verfügbar wäre, könnten Sie einfach schreiben:
was das gleiche "Tick" -Problem wie zuvor entfernen würde. Ich werde versuchen, daran zu erinnern, das für 2.0 hinzuzufügen - obwohl es mit einem Kommentar zu dem Effekt von "Nur verwenden, wenn Sie von Legacy-Systemen gezwungen werden" dokumentiert werden:)
Ein Nachteil des Hinzufügens eines Tages und des Subtrahierens eines Ticks (oder einer Nanosekunde) ist, dass es bei LocalDate.MaxValue fehlschlägt. Dies ist wahrscheinlich kein praktisches Problem, aber für Code innerhalb von Noda Time selbst versuchen wir solche Dinge zu vermeiden. Ich würde nicht versuchen, es für die ZonedDateTime Version zu vermeiden, da es ein ziemlich komplizierteres Szenario ist. (Es gibt wahrscheinlich Möglichkeiten, es zu tun, aber es wäre es nicht wert.)