Comments 18
Вывод: Не используйте MySQL.
Это какой то ахтунг, а не ожидаемое поведение, при чем там, где этого ну уж НИКАК не должно быть.
Это какой то ахтунг, а не ожидаемое поведение, при чем там, где этого ну уж НИКАК не должно быть.
Лет 10 использую MySQL и никогда не сталкивался с данной проблемой
Вывод — читайте документацию. Если сказано, «это может не работать» — не пытайтесь это использовать.
Во-первых, в описании поведения MIN() об этом не сказано ни слова. То что MIN применительно к датам неявно использует какое-то преобразование автор сам догадался и оказался прав.
Во-вторых, нормальная СУБД в таком случае должна сообщить об ошибке, а не тихонько промолчать, вернув неверный результат.
P.S. Вообще MySQL в мире СУБД напоминает мне PHP в мире ЯП: куцый функционал, зачастую неявное поведение, но все им почему-то пользуются.
Во-вторых, нормальная СУБД в таком случае должна сообщить об ошибке, а не тихонько промолчать, вернув неверный результат.
P.S. Вообще MySQL в мире СУБД напоминает мне PHP в мире ЯП: куцый функционал, зачастую неявное поведение, но все им почему-то пользуются.
Документация к MySQL 5.5 заявляет, что поддерживаемый диапазон дат в типе DATETIME составляет от 1000-01-01 00:00:00 до 9999-12-31 23:59:59. В продолжении говорится, что «Для DATE и DATETIME, „поддерживаемый“ означает то, что значения меньше могут работать, но гарантии нет». Выходило, что приложение занесло в базу странный datetime, и благодаря тому, что значение прошло проверку формата и попало в базу данных. Упс…
Зато сказано в описании к типу, что если воткнете дату ниже, может глючить все вообще (а может и не глючить, но мы вас предупредили).
Ругаться должна, тут не спорю. Может в следующей версии и будет, если сообщить об этой фишке авторам.
Я думал, тут будет загадка в стиле «Какой год длится ровно 1 день?» А тут все серьезней.
Всегда очень интересно, когда люди докапываются до сути вещей. Даже сам процесс увлекателен.
Мне кажется, что большинство остановилось бы после
Всегда очень интересно, когда люди докапываются до сути вещей. Даже сам процесс увлекателен.
Мне кажется, что большинство остановилось бы после
Ответ, который вернулся, был совсем другим: 2011-08-22 11:27:27. Это правильный ответ
Судя по мануалу dev.mysql.com/doc/refman/5.6/en/datetime.html
Диапазон дат для типа datetime от '1000-01-01 00:00:00' до '9999-12-31 23:59:59'
Включение стрикт режима должно помочь избежать ситуаций со вставкой 0024-06-21
Так же в одной из статей проскакивало, что стоит использовать STR_TO_DATE для избежания сюрпризов выборки и сортировки.
Поправьте если я не прав…
Диапазон дат для типа datetime от '1000-01-01 00:00:00' до '9999-12-31 23:59:59'
Включение стрикт режима должно помочь избежать ситуаций со вставкой 0024-06-21
Так же в одной из статей проскакивало, что стоит использовать STR_TO_DATE для избежания сюрпризов выборки и сортировки.
Поправьте если я не прав…
C:
выведет «EPIC FAIL!»
и что ж теперь, все, пипец, си — говно?!
float a = 0.7;
double b = 0.7;
if( a==b ) puts("OK"); else puts("EPIC FAIL!");
выведет «EPIC FAIL!»
и что ж теперь, все, пипец, си — говно?!
Не путайте теплое с мягким: C — это язык для разработчиков, то есть специально обученных программированию людей, которые должны разбираться в тонкостях их специальности. А MySQL — это конечный продукт для пользователя, не обязательно разбирающегося в программировании и результаты выполнения его операций должны быть строго специфицированы и понятны. Поэтому такие вещи в MySQL, по-хорошему, недопустимы. А для C — это нормально.
MySQL — это конечный продукт для пользователя
wat.
wat.
Вы баг зафайлили против MySQL?
По-моему это баг. Впрочем, как сказано в этом комментарии (http://www.mysqlperformanceblog.com/2012/09/04/odd_date_values_and_input_range_checking/comment-page-1/#comment-1017855) в 5.6 он пофикшен.
Sign up to leave a comment.
Когда MIN(DATE) != MIN(DATE)?