No warning was generated when a TIMESTAMP with a non-zero time part
 was converted to a DATE value. This caused index lookup to assume
 that this is a valid conversion and was returning rows that match 
 a comparison between a TIMESTAMP value and a DATE keypart.
 Fixed by generating a warning on such a truncation.


mysql-test/r/derived.result:
  Bug #31221: fixed an existing not-precise test case
mysql-test/r/ps_2myisam.result:
  Bug #31221: Warnings cased by existing tests
mysql-test/r/ps_3innodb.result:
  Bug #31221: Warnings cased by existing tests
mysql-test/r/ps_4heap.result:
  Bug #31221: Warnings cased by existing tests
mysql-test/r/ps_5merge.result:
  Bug #31221: Warnings cased by existing tests
mysql-test/r/ps_6bdb.result:
  Bug #31221: Warnings cased by existing tests
mysql-test/r/ps_7ndb.result:
  Bug #31221: Warnings cased by existing tests
mysql-test/r/type_date.result:
  Bug #31221: Warnings cased by existing tests
mysql-test/r/type_datetime.result:
  Bug #31221: test case
mysql-test/t/derived.test:
  Bug #31221: fixed an existing not-precise test case
mysql-test/t/type_date.test:
  Bug #31221: test case
sql/field.cc:
  Bug #31221: 
   - Upgraded fix for bug 29729
   - issue a warning only if the hh:mm:ss.msec is not zero consistently 
     for all the Field_newdate::store function
sql/item_timefunc.cc:
  Bug #31221: don't ignore the errors when storing data