View Ticket
Not logged in
Ticket Hash: 3e783eecbe52c5cc39e6fd1114cf917645e713ca
Title: multiple problems with SQLiteDateFormats.JulianDay
Status: Closed Type: Code_Defect
Severity: Important Priority: Blocker
Subsystem: Convert Resolution: Fixed
Last Modified: 2015-03-04 19:27:49
Version Found In: 1.0.94
User Comments:
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,


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 release.