Re: bk commit into 5.0 tree (tnurnberg:1.2597) BUG#32770

[Georgi Kodinov]

Hi,

On 10.12.2007, at 10:17, Tatjana A Nuernberg wrote:

> ChangeSet@stripped, 2007-12-10 09:17:18+01:00, tnurnberg@stripped +3 -0
>  Bug#32770: LAST_DAY() returns a DATE, but somehow internally keeps  
> track of the TIME.
>
>  LAST_DAY() says it returns a DATE, not a DATETIME, but didn't zero  
> the time fields.
>  Adapted from a patch kindly supplied by Claudio Cherubino.
>
>  mysql-test/r/func_time.result@stripped, 2007-12-10 09:17:16+01:00, tnurnberg@stripped 
>  +3 -0
>    show that LAST_DAY() returns only a DATE, not a DATETIME
>
>  mysql-test/t/func_time.test@stripped, 2007-12-10 09:17:17+01:00, tnurnberg@stripped 
>  +7 -0
>    show that LAST_DAY() returns only a DATE, not a DATETIME
>
>  sql/item_timefunc.cc@stripped, 2007-12-10 09:17:17+01:00, tnurnberg@stripped 
>  +2 -0
>    zero time-fields as we return only a DATE

OK to push.
It seems that the rule "MYSQL_TIMESTAMP_DATE has no time parts" (and  
related) is enforced at value storage time. So It would be an idea to  
add an assert at (some of) value retrieval time that this rule is  
still valid, e.g. Item_date_add_interval (<date> += INTERVAL  
<interval>) or CAST, or val_str() where the time part would matter.  
This will allow us to catch similar bugs in the future.

Best Regards,
Joro
-- 
Georgi Kodinov, Senior Software Engineer
MySQL AB, Plovdiv, Bulgaria, www.mysql.com
Office: [phone] Mobile: [phone] Skype: georgekodinov

Are you MySQL certified?  www.mysql.com/certification