mysql DATE_SUB() и STR_TO_DATE() странности

DATE_SUB() връща различен резултат при следните уж 'еднакви' извиквания:

mysql> SELECT DATE_SUB('8-02-31', INTERVAL 0 DAY) AS BB;

+------+

| BB   |

+------+

| NULL |

+------+

1 row in set, 1 warning (0.01 sec)

 

mysql> select @TMP_DATE_AA:=STR_TO_DATE('8-2-31','%Y-%m-%d') AS AA, DATE_SUB(@TMP_DATE_AA, INTERVAL 0 DAY) AS BB ;

+------------+------+

| AA         | BB   |

+------------+------+

| 2008-02-31 | NULL |

+------------+------+

1 row in set, 1 warning (0.00 sec)

 

mysql> SELECT DATE_SUB(STR_TO_DATE('8-2-31','%Y-%m-%d'), INTERVAL 0 DAY) AS BB;

+------------+

| BB         |

+------------+

| 2008-03-02 |

+------------+

1 row in set (0.00 sec)

Очевидно, в последния вариант вместо NULL прави корекция на датата.

1. Защо се получава така?
2. иииии има ли по-читав начин за проверка на валидност на дата?

не е проблем да прежаля вариант 3 и да карам на един от първите два, но ще стане кофти ако някой ден решат и тях да ги направят да връщат оправена дата вместо NULL. може би сравняването на резултите от STR_TO_DATE() и DATE_SUB() би било достатъчно надеждно, но се колебая.

Aaaaahh my little Rome, enjoy my flames

Ами отговорът е пред теб. :)

При първия вариант: за MySQL това '8-02-31' е просто някакъв стринг, а не дата. Кое в него еднозначно е годината, кое месеца, кое деня? Няма как да ти върне нещо различно от NULL;

При втория вариант: Само с един SELECT няма как едновременно да инициализираш променливата @TMP_DATE_AA и да я използваш. Нормално е ВВ отново да е NULL;

При третия вариант: Всичко е ОК - първо казваш, че тоя стринг аджеба е дата и след това прилагаш върху нея DATE_SUB. MySQL ти връща коректна стойност.

Има три вида хора. Част от проблема, част от решението и част от пейзажа.

звучи логично. благодаря!

Aaaaahh my little Rome, enjoy my flames