Prevent SQLite from messing with timezone offset of DateTime. #1374
Conversation
There was a problem hiding this comment.
As said in #1362, I think this hack should be configurable, if we really want to fix this SQLite issue on NHibernate side.
| @@ -52,7 +52,7 @@ protected AbstractDateTimeType(SqlType sqlTypeDateTime) : base(sqlTypeDateTime) | |||
| /// <param name="dateValue">The <see cref="System.DateTime" /> to adjust.</param> | |||
| /// <returns>A <see cref="System.DateTime" />.</returns> | |||
| protected virtual DateTime AdjustDateTime(DateTime dateValue) => | |||
| Kind == DateTimeKind.Unspecified ? dateValue : DateTime.SpecifyKind(dateValue, Kind); | |||
| DateTime.SpecifyKind(dateValue, Kind); | |||
There was a problem hiding this comment.
Is really this change required? SQLite users working with DateTimeKind=UTC would have a legitimate grievance with this change, as it would wreck their reading of dates, causing them to be unspecified instead of being said as UTC, and forcing them to use NHibernate Utc types instead.
I do not think we should force unspecified unless really having a compelling reason to do it. I think the NHibernate "unspecified" types should have as semantic "no change at all to read date kind", as was doing TimestampType previously (which is now become DateTimeType.) The fact that previous DateTimeType, cutting fractional seconds, is losing the kind, was likely accidental design. (DateTimeNoMsType probably still does that indeed.)
There was a problem hiding this comment.
I think it should stay the way it is without any configuration. See the unit test I created and my comment on the issue.
|
Replaced by #1378 |
This addresses #1362 by writing all
DateTimeparameter values to SQLite asDateTimeKind.Unspecified.This should work even when the connection string has
;DateTimeKind=Utc, as the ADO.Net driver uses that to mung allDateTimevalues to Utc on reading back, irregardless of how they were saved.