|Title:||multiple problems with SQLiteDateFormats.JulianDay|
|Last Modified:||2015-03-04 19:27:49|
|Version Found In:||1.0.94|
anonymous added on 2014-10-31 17:37:16:
* when you store the date "0001-01-01" (DateTime.MinValue) then rereading the value returns "1899-12-30" (because DateTime.MinValue.ToOADate() returns "0" and not ~"-693593" and so already the storage is wrong)
* reading correctly stored dates in the range 0001-01-01 till 0099-12-31 throws exception "Not a legal OleAut date" at DateTime.FromOADate()
* writing any DateTime which is larger than 0001-01-01 and smaller than 0100-01-01 also throws exception "Not a legal OleAut date" at DateTime.ToOADate()
Conclusion: Neither use dateTimeInstance.ToOADate() nor DateTime.FromOADate() for julian day calculations.
mistachkin added on 2014-10-31 20:32:29:
I suspect this issue has existed in the code for quite some time? If so, changing it now could introduce a backwards compatibility issue (i.e. even if the current behavior is incorrect).
mistachkin added on 2014-10-31 21:39:19:
Some experimental work on this issue is being done on the "newJulianDay" branch, here: [/timeline?r=newJulianDay] However, these changes will not necessarily be included in a release. Further evaluation of them is ongoing.
mistachkin added on 2014-11-01 18:39:47:
After some careful testing, I think that the only behavioral difference is going to be that the new method used will not throw exceptions for the values that are out of range of an OLE Automation Date.
anonymous added on 2014-11-05 14:53:40:
So chances are high this will included in 1.0.95 or 1.0.96?
mistachkin added on 2014-11-05 18:52:32:
Yes, since this change appears to be less risky than my original assessment.
mistachkin added on 2014-11-18 22:11:03:
Fixed on trunk via check-in [3bd76a0c9d]. To clarify, this fix *WILL* be in the 22.214.171.124 release.