有时我将时间戳记存储到sql Server 2008数据库.我传统上使用UTC的datetime2字段.这些时间戳将使用Noda创建.似乎这个日期转换为Noda的Instant可能是不受欢迎的.
我应该用什么类型来坚持？
如果我在sql中使用非整数,那么我的应用层和我的DAL之间有潜在的转换问题.但是,如果我保持整数Noda即时,我将具有相同层之间的逻辑耦合…我将无法在sql中执行简单的日期聚合,而不会将其带入应用层或CLR.
Noda在UTC时间内无法可靠地描述时间,因为某些时候从来没有发生在UTC.
解决方法
或者,如果要显式地显示值是基于UTC(偏移量始终为零),则可以使用sql datetimeoffset类型.有即时即可使用ToDateTimeOffset和FromDateTimeOffset方法.
你说：
Noda makes the case that instants can’t reliably be described in UTC,since certain times never occurred in UTC.
我想也许你被赶上了the user guide年的措辞.我可以看到它会如何引导你走上这条思路.虽然逻辑上一个Instant并不代表UTC,但它肯定可以用UTC来可靠地描述.也可以用其他一些术语来描述,只要这些术语是明确的.
用户指南所做的一点是,其他不在UTC的值仍然可以转换为Instant.例如,我可能有一个OffsetDateTime,或者一个具有与零不同的偏移量的DateTimeOffset,并且仍然可以将其调整为零以形成Instant.同样,我可能有一个分配给UTC时区或其他时区的ZonedDateTime,我仍然可以恢复到单个通用即时而不会失去保真度.
DateTime(除非它有DateTimeKind.Utc)或LocalDateTime,LocalDate,LocalTime等都不能说同样的,没有一个是明确的一个时刻.
至于其他的映射：
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)
