[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