Когда MIN(DATE) != MIN(DATE)?

[@SowingSadness]

Вывод: Не используйте MySQL.
Это какой то ахтунг, а не ожидаемое поведение, при чем там, где этого ну уж НИКАК не должно быть.

[@lifestar]

Лет 10 использую MySQL и никогда не сталкивался с данной проблемой

[@VoVanJinn]

Каждый настоящий программист должен в своей жизни хотя бы раз доковырять до критического бага и создать тикет )

[@StamPit]

Либо написать workaround. :-)

[@Goodkat]

unix_timestamp для 9999-12-31 возвращает некорректное значение, поэтому приходится воркэраундить :)

[@Newbilius]

Вывод — читайте документацию. Если сказано, «это может не работать» — не пытайтесь это использовать.

[@LighteR]

Во-первых, в описании поведения MIN() об этом не сказано ни слова. То что MIN применительно к датам неявно использует какое-то преобразование автор сам догадался и оказался прав.
Во-вторых, нормальная СУБД в таком случае должна сообщить об ошибке, а не тихонько промолчать, вернув неверный результат.

P.S. Вообще MySQL в мире СУБД напоминает мне PHP в мире ЯП: куцый функционал, зачастую неявное поведение, но все им почему-то пользуются.

[@Newbilius]

Документация к MySQL 5.5 заявляет, что поддерживаемый диапазон дат в типе DATETIME составляет от 1000-01-01 00:00:00 до 9999-12-31 23:59:59. В продолжении говорится, что «Для DATE и DATETIME, „поддерживаемый“ означает то, что значения меньше могут работать, но гарантии нет». Выходило, что приложение занесло в базу странный datetime, и благодаря тому, что значение прошло проверку формата и попало в базу данных. Упс…

Зато сказано в описании к типу, что если воткнете дату ниже, может глючить все вообще (а может и не глючить, но мы вас предупредили).
Ругаться должна, тут не спорю. Может в следующей версии и будет, если сообщить об этой фишке авторам.

[@bunya]

Я думал, тут будет загадка в стиле «Какой год длится ровно 1 день?» А тут все серьезней.
Всегда очень интересно, когда люди докапываются до сути вещей. Даже сам процесс увлекателен.
Мне кажется, что большинство остановилось бы после

Ответ, который вернулся, был совсем другим: 2011-08-22 11:27:27. Это правильный ответ

[@coh]

Судя по мануалу 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 для избежания сюрпризов выборки и сортировки.

Поправьте если я не прав…

[@zed_0xff]

C:

float  a = 0.7;
double b = 0.7;
   
if( a==b ) puts("OK"); else puts("EPIC FAIL!");

выведет «EPIC FAIL!»

и что ж теперь, все, пипец, си — говно?!

[@rusabakumov]

Не путайте теплое с мягким: C — это язык для разработчиков, то есть специально обученных программированию людей, которые должны разбираться в тонкостях их специальности. А MySQL — это конечный продукт для пользователя, не обязательно разбирающегося в программировании и результаты выполнения его операций должны быть строго специфицированы и понятны. Поэтому такие вещи в MySQL, по-хорошему, недопустимы. А для C — это нормально.

[@zed_0xff]

Я блондинка, я не хочу заправлять/прогревать/мыть мой автомобиль, я хочу би-би и вжжжжжж!!!

[@rusabakumov]

Такой подход недопустим при программировании на С, но вполне обычен при использовании СУБД

[@spacediver]

MySQL — это конечный продукт для пользователя

wat.

[@rusabakumov]

В большом количестве вакансий, не связанных напрямую с программированием часто требуется знание SQL — например, в аналитике. В этом случае используемая СУБД, к которой будут задаваться запросы, будет конечным продуктом для таких пользователей.

[@23derevo]

Вы баг зафайлили против MySQL?

[@svetasmirnova]

По-моему это баг. Впрочем, как сказано в этом комментарии (http://www.mysqlperformanceblog.com/2012/09/04/odd_date_values_and_input_range_checking/comment-page-1/#comment-1017855) в 5.6 он пофикшен.