From: Date: December 11 2007 2:51pm
Subject: Re: bk commit into 5.0 tree (tnurnberg:1.2597) BUG#32770
List-Archive: http://lists.mysql.com/commits/39707
Message-Id: <7C7F2AC1-19EE-46A5-9F75-415802A68441@mysql.com>
MIME-Version: 1.0 (Apple Message framework v915)
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

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: +359 32 634 397 Mobile: +359 887 700 566 Skype: georgekodinov

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