Re: CURDATE() bug?
Hi, - Original Message - From: Alan Williamson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 5:17 PM Subject: CURDATE() bug? Could anyone tell me if this is a bug or not. SQL: SELECT CURDATE()+0; RESULT: 20040331 Thats good. However consider this: SQL: SELECT CURDATE()+1; RESULT: 20040332 Not so good. Infact with this version any WHERE clauses you would put this in, fails to bring back the right result. Does CURDATE() support numeric addition like this? Or is the +0 purely a casting-hack to get the right format. Its not meant as pure addition. Yes, hav a look at http://www.mysql.com/doc/en/Date_and_time_functions.html for explaination further for addition, use date_add(curdate(), interval 1 day) or watever Thoughts? thanks alan -- Alan Williamson, City Planner w: http://www.BLOG-CITY.com/ e: [EMAIL PROTECTED] b: http://alan.blog-city.com/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] HTH... Nitin -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: CURDATE() bug?
I would say that the CURDATE is converted to an integer because of +0. Since if you add 1 to a date, should that increment years/months/days/ or seconds ? Use the DATE_ADD(date,INTERVAL expr type) functions instead. cheers mike -Original Message- From: Alan Williamson [mailto:[EMAIL PROTECTED] Sent: Wednesday, 31 March 2004 9:47 PM To: [EMAIL PROTECTED] Subject: CURDATE() bug? Could anyone tell me if this is a bug or not. SQL: SELECT CURDATE()+0; RESULT: 20040331 Thats good. However consider this: SQL: SELECT CURDATE()+1; RESULT: 20040332 Not so good. Infact with this version any WHERE clauses you would put this in, fails to bring back the right result. Does CURDATE() support numeric addition like this? Or is the +0 purely a casting-hack to get the right format. Its not meant as pure addition. Thoughts? thanks alan -- Alan Williamson, City Planner w: http://www.BLOG-CITY.com/ e: [EMAIL PROTECTED] b: http://alan.blog-city.com/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: CURDATE() bug?
Could anyone tell me if this is a bug or not. SQL: SELECT CURDATE()+0; RESULT: 20040331 Thats good. However consider this: SQL: SELECT CURDATE()+1; RESULT: 20040332 Not so good. Infact with this version any WHERE clauses you would put this in, fails to bring back the right result. Does CURDATE() support numeric addition like this? Or is the +0 purely a casting-hack to get the right format. Its not meant as pure addition. NOT A BUG!!! In the manual it is stated that CURDATE() returns either -MM-DD or MMDD depending on the context. So in the context of addition with an integer it will return MMDD which is automatically cast to integer when adding either 0 or 1. If you use SELECT CURDATE() + INTERVAL 1 DAY; it will return 2004-04-01 and SELECT ( CURDATE( ) + INTERVAL 1 DAY ) +0 will return 20040401 Regards, Jigal. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: CURDATE() bug?
Could anyone tell me if this is a bug or not. SQL: SELECT CURDATE()+0; RESULT: 20040331 Thats good. However consider this: SQL: SELECT CURDATE()+1; RESULT: 20040332 Not so good. Infact with this version any WHERE clauses you would put this in, fails to bring back the right result. Does CURDATE() support numeric addition like this? Or is the +0 purely a casting-hack to get the right format. Its not meant as pure addition. NOT A BUG!!! In the manual it is stated that CURDATE() returns either -MM-DD or MMDD depending on the context. So in the context of addition with an integer it will return MMDD which is automatically cast to integer when adding either 0 or 1. If you use SELECT CURDATE() + INTERVAL 1 DAY; it will return 2004-04-01 and SELECT ( CURDATE( ) + INTERVAL 1 DAY ) +0 will return 20040401 Regards, Jigal. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: CURDATE() bug?
Could anyone tell me if this is a bug or not. SQL: SELECT CURDATE()+0; RESULT: 20040331 Thats good. However consider this: SQL: SELECT CURDATE()+1; RESULT: 20040332 Not so good. Infact with this version any WHERE clauses you would put this in, fails to bring back the right result. Does CURDATE() support numeric addition like this? Or is the +0 purely a casting-hack to get the right format. Its not meant as pure addition. NOT A BUG!!! In the manual it is stated that CURDATE() returns either -MM-DD or MMDD depending on the context. So in the context of addition with an integer it will return MMDD which is automatically cast to integer when adding either 0 or 1. If you use SELECT CURDATE() + INTERVAL 1 DAY; it will return 2004-04-01 and SELECT ( CURDATE( ) + INTERVAL 1 DAY ) +0 will return 20040401 Regards, Jigal. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: CURDATE() bug?
Does CURDATE() support numeric addition like this? Or is the +0 purely a casting-hack to get the right format. Its not meant as pure addition. Yes, hav a look at http://www.mysql.com/doc/en/Date_and_time_functions.html for explaination further for addition, use date_add(curdate(), interval 1 day) or watever i know how to add dates, that wasn't the point of the post! but thank you nonetheless! ;) I was merely looking for clarification. If +0 is purely a casting hack then it should be highlighted as such so people don't assume. By using +0 does suggest its a numerical addition and therefore why stop at 0. Why not 1 etc etc etc. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: CURDATE() bug?
- Original Message - From: Alan Williamson [EMAIL PROTECTED] To: Jigal van Hemert [EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 2:05 PM Subject: Re: CURDATE() bug? Jigal van Hemert wrote: NOT A BUG!!! In the manual it is stated that CURDATE() returns either -MM-DD or MMDD depending on the context. So in the context of addition with an integer it will return MMDD which is automatically cast to integer when adding either 0 or 1. sorry ... but disagree with you, it is a bug. Casting is a very dangerous business at the best of times. It is a bug. Its a hack. But hacks can be good. However, one can't make assumptions on hacks. The documentation is not clear at all in this area. The value in which you cast is important; so your assumption that 0 or 1 makes no difference is incorrect. Simply an addition to the documentation to clarify that this is purely a formatting hack and should not be used to do date addition would satisfy all. RTFM! It gives you plenty of examples for manipulating dates and the output of of curdate() is clearly stated with examples. No-one can help it that you don't like it the way it is. You provided the same example as the manual (CURDATE() + 0) and got the same result as the manual says. Then you do an addition and you're surprised that the result is an integer? Have you tried something like SELECT '1tt' +2; ? The result may be a surprise for you (3), but if you read the manual about how MySQL handles types (e.g. http://www.mysql.com/doc/en/String_comparison_functions.html) it is expected behaviour and not a bug IMHO. The fact that something takes different values in different contexts is not very strange. Languages such as Perl will give you various examples. The +0 is not a hack, but provides a numerical context for the function CURDATE(), which modifies its behaviour. Regards, Jigal. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: CURDATE() bug?
RTFM! and what was the reason for this rudeness? Can't you explain yourself without descending into this sort of language? I do read the manual, and it is this reason i posted to the list. Clarity is a wonderful thing, and sadly the manual isn't clear on this matter. I stand by my original statement. If you believe it not to be a bug then so be it; we agree to disagree. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: CURDATE() bug?
RTFM! and what was the reason for this rudeness? Can't you explain yourself without descending into this sort of language? My apologies for any rudeness, English is not my first language and I'm used to using this abbreviation to indicate that it can be found in the manual. I do read the manual, and it is this reason i posted to the list. It was not clear after your first post that you actually read the manual. Only after people explained it to you, it became clear that you didn't ask because you didn't know about the output of CURDATE(), but rather because you wanted to discuss the fact that MySQL automatically converts between numbers and strings (which has very little to do with CURDATE actually). The fact that you asked about one thing only to discuss another thing did irritate me a bit. People here are mostly quite willing to help any level of users and if they take the time to help you get CURDATE() working only to read later that you know how to handle dates (i know how to add dates, that wasn't the point of the post!) is a bit frustrating (in my oppinion anyway). Clarity is a wonderful thing, and sadly the manual isn't clear on this matter. I stand by my original statement. If you believe it not to be a bug then so be it; we agree to disagree. It's very clear IMHO: it says that CURDATE() produces two kinds of formats, depending on the context and demonstrates this with two examples. Furthermore the autoconversion between strings and numbers is also explained. Best regards, Jigal. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
