We just updated a development server from Ubuntu 6.06 to 6.10. As a result, MySQL went up a couple of point releases from 5.0.22 to 5.0.24a.
Suddenly, the web application we were working on stopped working. It wasn’t possible to log in.
We quickly narrowed it down to a clause in query which checked a users subscription was valid by checking its start and end dates. It looked bit like this:
SELECT foo FROM bar WHERE NOW() BETWEEN start AND end;
MySQL 5.0.22 returned rows, but 5.0.24 didn’t. After scratching our heads, I checked the manual:
For best results when using BETWEEN with date or time values, you should use CAST() to explicitly convert the values to the desired data type. Examples: If you compare a DATETIME to two DATE values, convert the DATE values to DATETIME values. If you use a string constant such as ‘2001-1-1’ in a comparison to a DATE, cast the string to a DATE.
The phrase “best results” make it sound like we’re baking a cake, and that your query results will be fluffier and more flavoursome if you use CAST! What they actually mean is, if you’re comparing different date types, you’re screwed if you don’t cast. You might get nothing.
Sure enough, our start and end columns were dates, and using cast in the query worked just fine:
SELECT foo FROM bar WHERE CAST(NOW() AS DATE) BETWEEN start AND end;
I couldn’t find anything directly related to this change in behaviour in the changelogs, but hopefully this will help someone out there…
Hi,
sometimes there are tiny little things that may *eat* your day.
thanks for sharing.
Slavi
Just saved me a lot of time. THANKS
Great post – thanks! I ended up using a slightly different approach:
SELECT * FROM table WHERE UNIX_TIMESTAMP(col1) > UNIX_TIMESTAMP(userentry)
This gave me two numbers to do math from rather than dates to compare.
Thanks 😉