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]
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?
- 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?
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?
> 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?
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?
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]
