Wie sollte ich Zeitstempel in SQL DB beibehalten, wenn App NodaTime verwendet?

Question

Ich möchte NodaTime in meiner Anwendung verwenden, um Zeiten, Zeitpunkte und allgemeine Zeitlokalisierung zu verwalten.

Manchmal behalte ich Zeitstempel zu einer SQL Server 2008-Datenbank. Ich hatte datetime2 Felder traditionell in UTC verwendet. Diese Zeitstempel werden mit Noda erstellt. Es scheint, dass diese Datumsumwandlung zu Nodas Instant möglicherweise unerwünscht ist.

Welchen Typ sollte ich verwenden, um sie zu erhalten?

Wenn ich eine Nicht-Ganzzahl in SQL verwende, dann habe ich potenzielle Konvertierungsprobleme zwischen meiner App-Ebene und meinem DAL. Wenn ich jedoch die Ganzzahl Noda Instant beibehalten würde, würde ich eine logische Kopplung zwischen den gleichen Layern haben ... und ich werde keine einfachen Datumsaggregationen in SQL durchführen können, ohne sie in die App-Ebene oder CLR zu bringen.

Noda macht den Fall, dass Zeitpunkte nicht zuverlässig in UTC beschrieben werden können, da bestimmte Zeiten nie in UTC aufgetreten sind.

Answer 1

Ein datetime2 ist ein vollkommen akzeptabler und normaler SQL-Typ zum Speichern eines Instant. Verwenden Sie die Instant.ToDateTimeUtc-Methode, um eine DateTime zu erhalten, und speichern Sie diese dann wie gewohnt in SQL. Ebenso können Sie die Methode Instant.FromDateTimeUtc verwenden, wenn Sie den Wert aus SQL abrufen.

Alternativ könnten Sie einen SQL-Typ datetimeoffset verwenden, wenn Sie explizit angeben möchten, dass die Werte UTC-basiert sind (der Offset ist immer Null). Es gibt ToDateTimeOffset und FromDateTimeOffset Methoden auf Instant Sie verwenden können.

Sie sagte:

Noda den Fall macht, die Zeitpunkte in UTC nicht verlässlich beschrieben werden kann, da bestimmte Zeiten nie in UTC aufgetreten.

Ich denke, vielleicht sind Sie in der Formulierung in the user guide gefangen. Ich kann sehen, wie es dich in diese Richtung führen könnte. Es stimmt zwar, dass logisch ein Instant nicht UTC darstellt, kann es durchaus sein, zuverlässig in Bezug auf UTC beschrieben. Es könnte auch in einigen anderen Begriffen beschrieben werden, solange diese Begriffe eindeutig waren.

Der Punkt, den das Benutzerhandbuch macht, ist, dass andere Werte, die nicht in UTC sind, noch in eine Instant konvertiert werden können. Zum Beispiel könnte ich ein OffsetDateTime oder ein DateTimeOffset habe, die ein unterschiedlichen als Nullpunktverschiebung hat, und es könnte immer noch zurück auf Null eingestellt werden, um ein Instant zu bilden. Ebenso könnte ich eine ZonedDateTime haben, die der UTC-Zeitzone oder einer anderen Zeitzone zugeordnet ist, kann ich auf einen einzigen universellen Instant ohne Verlust der Treue immer noch zurück.

Dasselbe kann nicht von DateTime gesagt werden (es sei denn, es hat DateTimeKind.Utc) oder von LocalDateTime, LocalDate, LocalTime usw. Keiner von denen ist eindeutig ein Augenblick in der Zeit.

Was die anderen Zuordnungen:

Noda Time  | .NET BCL     | SQL Server 
---------------|----------------------------|------------------------------------------ 
Instant  | DateTime or DateTimeOffset | datetime2 or datetimeoffset 
OffsetDateTime | DateTimeOffset    | datetimeoffset 
LocalDateTime | DateTime     | datetime2 
LocalDate  | DateTime     | date 
LocalTime  | TimeSpan     | time 
Duration  | TimeSpan     | int or bigint (Ticks, TotalSeconds, etc.) 
Period   | String      | varchar 
ZonedDateTime | DateTimeOffset + String | datetimeoffset + varchar (or a UDT)