[Mono-bugs] [Bug 77268][Wis] Changed - Sqlite DateTime Parameters Handled Incorrectly
bugzilla-daemon at bugzilla.ximian.com
bugzilla-daemon at bugzilla.ximian.com
Tue Jul 4 07:44:08 EDT 2006
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by anmar at gmx.net.
http://bugzilla.ximian.com/show_bug.cgi?id=77268
--- shadow/77268 2006-07-04 07:02:32.000000000 -0400
+++ shadow/77268.tmp.22825 2006-07-04 07:44:08.000000000 -0400
@@ -10,13 +10,12 @@
Component: Sys.Data.SqlClient
AssignedTo: tsenganal at novell.com
ReportedBy: jhill at arcfocus.com
QAContact: mono-bugs at ximian.com
TargetMilestone: ---
URL:
-Cc:
Summary: Sqlite DateTime Parameters Handled Incorrectly
Description of Problem:
DbType.DateTime parameters are passed into SqliteCommands as numbers which
cannot be used for datetime comparison in Sqlite (for instance, using the
datetime functions provided with sqlite), and, if stored, will not be
@@ -183,6 +182,23 @@
I'd prefer 1) as it's the simplest to work with, and can be even done
in a somewhat backwards compatible way detecting the order of
magnitude of the stored number.
I'd be willing to provide patches for any of them.
+
+------- Additional Comments From anmar at gmx.net 2006-07-04 07:44 -------
+Sorry, the modifier code should read:
+ case 'd': {
+ if( strcmp(z, "dotnet")==0 && p->validJD ){
+ p->rJD = ((p->rJD/86400.0)/10000000.0) + 2305813.5;
+ p->rJD += localtimeOffset(p);
+ clearYMD_HMS_TZ(p);
+ rc = 0;
+ }
+ break;
+ }
+
+In the above case 1) it would be even simplier to be backwards
+compatible, as julian representation of date is returned by sqlite as
+double and current implementation as integer. Well and going
+julian->ticks is just ... trivial.
More information about the mono-bugs
mailing list