[odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a

[Hugo.Mildenberger at web.de]

Hi Boris,

 Boris Kolpackov <boris at codesynthesis.com> wrote:

 > I got your second email and realize the patch didn't fix anything.
 > I am still confused whether you were using MariaDB native client
 > (which, as I understand, is a re-implementation of the MySQL
 > client library) or you used the standard MySQL client library, or
 > maybe both. I am also not clear whether the tests fail with the
 > native client, standard client, both, or some versions of the
 > native client (I remember reading that a newer version of
 > something fixed something). As you can see, I am quite
 > confused... ;-)

 I'm sorry. I was myself quite confused about the many things that 
 what went astray. But I'm now again really using  
 libmysqlclient.so.18.0.0 which comes with mariadb-5.5.28a. 

 By the way, I missed the functionality to track the values passed to 
 mysql_stmt_bind_param(). The odb tracer classes were not of much help 
 with prepared statements.

 But now, after having implanted a tracer into libmysql.c instead, I 
 observed that the odb-test suite passed strange values for the 
 "second_part" field of MYSQL_TIME. This field is defined to represent 
 microseconds:   

 [+] 2013-02-07 11:25:10 7020097254353692004; libmysql.c +2050 in net_store_datetime()
 

 7020097254353692004 * 1E-6 seconds / 3600 / 24 / 365 = 222 605.8 years
 
 Previously, in accordance with the MySQL documentation, this field was
 unused.  Now MariaDB obviously attempts to normalize the date/time value.

 Using gdb, it is very difficult to follow all the conversions going on 
 between template code fragments. But commenting out all tests except 
 localtime finally showed that the culprit is
 
   o.times.push_back (second_clock::local_time ());

 Possibly this is not the only problematic conversion. I also noted 
 that the huge microsecond value remained constant across several 
 tests, hence it can not be derived from system time. 

 Hugo