ruby-dbi-devel-cvs

[Ruby-DBI-devel-CVS] CVS: src/lib/dbi sql.rb,1.13,1.14

[Michael N. <mne...@us...>]

Update of /cvsroot/ruby-dbi/src/lib/dbi
In directory sc8-pr-cvs1:/tmp/cvs-serv23497

Modified Files:
	sql.rb 
Log Message:
Fixed bug in DBI::SQL::BasicQuote::Coerce#as_time
Mysql time columns (like "13:32:33") could not be converted into DBI::Time objects 
(thanks to Tim Bates)


Index: sql.rb
===================================================================
RCS file: /cvsroot/ruby-dbi/src/lib/dbi/sql.rb,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- sql.rb	1 Feb 2003 13:45:23 -0000	1.13
+++ sql.rb	27 Apr 2003 17:37:02 -0000	1.14
@@ -47,9 +47,9 @@
       end
 
       def as_time(str)
-        return nil if str.nil?
-        t = as_timestamp(str)
-        DBI::Time.new(t.hour, t.min, t.sec)
+        return nil if str.nil? or str.empty?
+        t = ParseDate.parsedate(str)
+        DBI::Time.new(*t[3,3])
       end
 
 

Re: [Ruby-DBI-devel-CVS] CVS: src/lib/dbi sql.rb,1.13,1.14

[Paul D. <pa...@sn...>]

At 10:37 -0700 4/27/03, Michael Neumann wrote:
>Update of /cvsroot/ruby-dbi/src/lib/dbi
>In directory sc8-pr-cvs1:/tmp/cvs-serv23497
>
>Modified Files:
>	sql.rb
>Log Message:
>Fixed bug in DBI::SQL::BasicQuote::Coerce#as_time
>Mysql time columns (like "13:32:33") could not be converted into 
>DBI::Time objects
>(thanks to Tim Bates)

Speaking of coercion...

I've noticed that MySQL DATETIME and TIMESTAMP values get converted
into formats that don't really reflect how MySQL itself displays
them.  For example, a DATETIME value such as '2001-01-01 00:00:00'
gets coerced to '2001-1-1 0:0:0.0'.  Leading zeros are lost, and
a fraction-of-seconds part is added at the end.

Should this be considered a bug, or just something that MySQL
users should be aware of, and wary of?

>
>
>Index: sql.rb
>===================================================================
>RCS file: /cvsroot/ruby-dbi/src/lib/dbi/sql.rb,v
>retrieving revision 1.13
>retrieving revision 1.14
>diff -u -r1.13 -r1.14
>--- sql.rb	1 Feb 2003 13:45:23 -0000	1.13
>+++ sql.rb	27 Apr 2003 17:37:02 -0000	1.14
>@@ -47,9 +47,9 @@
>        end
>
>        def as_time(str)
>-        return nil if str.nil?
>-        t = as_timestamp(str)
>-        DBI::Time.new(t.hour, t.min, t.sec)
>+        return nil if str.nil? or str.empty?
>+        t = ParseDate.parsedate(str)
>+        DBI::Time.new(*t[3,3])
>        end
>

Re: [Ruby-DBI-devel-CVS] CVS: src/lib/dbi sql.rb,1.13,1.14

[Paul D. <pa...@sn...>]

At 20:49 +0200 4/27/03, Michael Neumann wrote:
>Paul DuBois wrote:
>>  At 10:37 -0700 4/27/03, Michael Neumann wrote:
>>  >Update of /cvsroot/ruby-dbi/src/lib/dbi
>>  >In directory sc8-pr-cvs1:/tmp/cvs-serv23497
>>  >
>>  >Modified Files:
>>  >	sql.rb
>>  >Log Message:
>>  >Fixed bug in DBI::SQL::BasicQuote::Coerce#as_time
>>  >Mysql time columns (like "13:32:33") could not be converted into
>>  >DBI::Time objects
>>  >(thanks to Tim Bates)
>>
>>  Speaking of coercion...
>>
>>  I've noticed that MySQL DATETIME and TIMESTAMP values get converted
>>  into formats that don't really reflect how MySQL itself displays
>>  them.  For example, a DATETIME value such as '2001-01-01 00:00:00'
>>  gets coerced to '2001-1-1 0:0:0.0'.  Leading zeros are lost, and
>>  a fraction-of-seconds part is added at the end.
>>
>>  Should this be considered a bug, or just something that MySQL
>>  users should be aware of, and wary of?
>
>The string we get from a Mysql database is parsed and converted into
>a DBI::Time object. When calling the to_s method of DBI::Time it
>is converted back into a string.
>
>Does Mysql handle '2001-1-1 0:0:0.0' correctly as a DATETIME value?

Yes, though this is because it ignores the fractional part (the .0)
at the end, which is not part of DATETIME or TIMESTAMP.


>And "0:0:0" for TIME values?

Yes.

>If not, than it's a bug, otherwise not.

On the other hand, your questions relate to putting data *into* MySQL.
Applications that expect DATETIME values to come *out* of Ruby DBI programs
the way that MySQL itself formats them may break.  (That is, if a
program assumes a string value in CCYY-MM-DD hh:mm:ss format, it cannot
break out parts of the value by looking for fixed-length-and-position
substrings.)  That's why I asked if this behavior is something MySQL
users should be wary of.

>
>When can of course modify the to_s method to output YYYY-MM-DD HH:MM:SS.F,
>that's no problem, except perhaps decreased performance (should be ok).

There would be no ".F" part for MySQL.

>
>Regards,
>
>   Michael