|
2015-03-04
| ||
| 19:27 | • Closed ticket [3e783eecbe]: multiple problems with SQLiteDateFormats.JulianDay plus 2 other changes artifact: 03f74b0468 user: mistachkin | |
|
2014-11-18
| ||
| 22:11 | • Fixed ticket [3e783eecbe]. artifact: 1aba55b2c1 user: mistachkin | |
| 22:11 | • Ticket [3e783eecbe]: 6 changes artifact: 92163987e3 user: mistachkin | |
|
2014-11-14
| ||
| 00:19 | Handle Julian Day values that fall outside of the supported range for OLE Automation dates. Fix for [3e783eecbe]. check-in: 3bd76a0c9d user: mistachkin tags: trunk | |
|
2014-11-05
| ||
| 18:52 | • Ticket [3e783eecbe] multiple problems with SQLiteDateFormats.JulianDay status still Open with 3 other changes artifact: 1dd8f50348 user: mistachkin | |
| 14:53 | • Ticket [3e783eecbe]: 3 changes artifact: 7cf0233065 user: anonymous | |
|
2014-11-01
| ||
| 18:39 | • Ticket [3e783eecbe]: 3 changes artifact: 1c4e93e991 user: mistachkin | |
|
2014-10-31
| ||
| 21:39 | • Ticket [3e783eecbe]: 3 changes artifact: 59acaf7f8c user: mistachkin | |
| 21:36 | Add experimental port of the Julian Day handling functions from the SQLite core library. Still needs tests. Pursuant to [3e783eecbe]. check-in: fe17cded54 user: mistachkin tags: newJulianDay | |
| 20:32 | • Ticket [3e783eecbe] multiple problems with SQLiteDateFormats.JulianDay status still Open with 6 other changes artifact: 4f1231a7ea user: mistachkin | |
| 17:37 | • New ticket [3e783eecbe]. artifact: 4389da39bf user: anonymous | |
| 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, 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 1.0.95.0 release. | ||||