extract data tier application sql server

¿Cómo debo persistir las marcas de tiempo en SQL DB si la aplicación usa NodaTime?

Question

Quiero comenzar a usar NodaTime en mi aplicación para administrar los tiempos, instantes y la localización general del tiempo.

A veces persisto las marcas de tiempo en una base de datos de SQL Server 2008. Tradicionalmente había usado los campos datetime2 en UTC. Estas marcas de tiempo se crearán utilizando Noda. Parece que esta conversión de fecha a Instant de Noda puede ser indeseable.

¿Qué tipo debo usar para persistirlos?

Si utilizo un no entero en SQL, tengo problemas potenciales de conversión entre mi capa de aplicación y mi DAL. Sin embargo, si persisto el instante entero de Noda, tendré un acoplamiento lógico entre las mismas capas ... y no podré realizar agregaciones de fechas simples en SQL sin llevarlo a la capa de aplicación o CLR.

Noda afirma que los instantes no se pueden describir de manera confiable en UTC, ya que ciertas veces nunca ocurrieron en UTC.

Answer 1

Un datetime2 es un tipo SQL perfectamente aceptable y normal para almacenar un Instant . Use el método Instant.ToDateTimeUtc para obtener un DateTime , luego guárdelo en SQL de manera normal. Del mismo modo, puede utilizar el método Instant.FromDateTimeUtc cuando recupere el valor de SQL.

Alternativamente, podría usar un tipo de conjunto de datos de SQL si quisiera ser explícito de que los valores están basados ​​en UTC (el desplazamiento siempre será cero). ToDateTimeOffset FromDateTimeOffset métodos ToDateTimeOffset y FromDateTimeOffset en Instant .

Tu dijiste:

Noda afirma que los instantes no se pueden describir de manera confiable en UTC, ya que ciertas veces nunca ocurrieron en UTC.

Creo que quizás estás atrapado en la redacción de la guía del usuario . Puedo ver cómo podría llevarte a esa línea de pensamiento. Si bien es cierto que, lógicamente, un Instant no representa UTC, ciertamente puede describirse de manera confiable en términos de UTC. También podría describirse en algunos otros términos, siempre que esos términos fueran inequívocos.

El punto que señala la guía del usuario es que otros valores que no están en UTC podrían convertirse a un Instant . Por ejemplo, podría tener un OffsetDateTime , o un DateTimeOffset que tiene un desplazamiento diferente a cero, y aún podría ajustarse de nuevo a cero para formar un Instant . Del mismo modo, es posible que tenga un ZonedDateTime asignado a la zona horaria UTC, o alguna otra zona horaria, todavía puedo volver a un solo Instant universal sin pérdida de fidelidad.

No se puede decir lo mismo de DateTime (a menos que tenga DateTimeKind.Utc ), o de LocalDateTime , LocalDate , LocalTime , etc. Ninguno de ellos es inequívocamente un solo instante en el tiempo.

En cuanto a las otras asignaciones:

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)