ну собственно что и требовалась доказать, и шагу сделать не успел как обделался
Если даже ты забыл про такую элементарщину как DST, то что тогда там накодят твои джуниоры? Багов говоришь там у вас почти нет, да просто нет сложных выборок, вот они и не проявляются

Подытожим наш спор, плюсы и минусы обоих подходов:

Работа со временем на стороне приложения
плюсы:
1 независим от способности хранилища работать с TZ и от синхронности tzdata в приложении и субд
2 независим от синхронности RTC, если приложение и субд разнесены по разным хостам
минусы:
1 необходимость постоянно помнить о конвертации и знать об исключительных случаях где она не нужна
2 необходимость уметь правильно работать со временем, учитывать зависимость смещения часового пояса нужной зоны от даты, и это не только DST
3 неоправданное усложнение запросов, и логики приложения
4 человеческий фактор значительно повышает вероятность багов из-за первых двух пунктов, там где их можно избежать
5 в случае работы с одной субд нескольких приложений с разных хостов, зависимость от синхронности их RTC и tzdata в приложениях

Работа со временем на стороне субд, плюсы и минусы обратны от таковых для предыдущего варианта.

Однозначного выбора как работать со временем я не вижу, все определяется конкретными условиями в которых приложение будет работать. Доя ширпотребных продуктов типа всяких CMS-ок лучше использовать первый подход, так как важна способность работать в любых условиях и повлиять на них разработчик не в состоянии. Для индивидуальных проектов, где есть возможность влиять на набор софта и администрирование, предпочтительней второй вариант.

Все эти изменения сразу же вносятся в базу данных IANA, время её внедрения в софте зависит от расторопности сборщиков дистрибутивов, от них должно прилететь обновление, и от админов, как они следят за обновлениями.

Всё гораздо хуже, мускул эту ответственность полностью переложил на своих клиентов, заполнять эти таблицы нужно ручками, и поддерживать актуальность то же. Может произойти так, что tzdata в PHP обновилась, а на мускул админы забили. Именно это я подразумевал под

Всё так, только я не пойму, почему нельзя комбинировать? Лично я при инсертах (ну и апдейтах естественно)
использую время запуска скрипта. Тут дело не в том, атомарные запросы или нет. Если данные вносятся одим скриптом, они априори должны быть с одним временем. Разница в долю секунды может организовать разницу в секунду, если на стыке. А если на стыке дат, то и в сутки. Кроме того, так проще добавлять запросы. Ну и вот такие баги с обновлениями нивелируются.

При выборке почти всегда использую возможности СУБД. И не по причине tz. У меня все работает исключительно по московскому времени. Нет другой необходимости, и постараюсь, чтобы небыло. А по причине того, что это гораздо удобнее, нежели кардабалет на стороне PHP. Со всякими билдерами, AR, ORM и иже с ними одна головная боль. На чистом SQL писать стократ приятнее, эфективнее, проще и быстрее.

UPD Не увидел этого:

С этим согласен полностью. Потому chee так и рассуждает, потому что у него ширпотребный проект.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

На практике я никогда не встречал ситуации когда нужно было учитывать этот фактор. Если бы я работал с такими запросами и видел бы в этом проблему, то наверное учел бы в запросе.

Судя по всему, решение с летним временем это взять дату в искомом интервале и извлечь время исходя из этой даты.

Если я правильно понимаю, то если есть прокся и за ней несколько одинаковых баз, то подобного рода проблема тоже имеет место быть и в твоем подходе.

Любое готовое универсальное решение - предназначена для потребления широкой аудитории, потому в нём и приходится использовать самые универсальные подходы, которые есть.

twin Если бы у меня как и у тебя был один проект с одной часовой зоной, то возможно я бы тоже рассуждал как ты, но мне не дано такое проклятие, потому я хоть что-то знаю в этой теме, в отличии от тебя и не "радуюсь как у меня тепло в болоте".


_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

А я тебя разве упрекал в этом? Я просто знаю, что ты юзаешь CMS, потому и высказал предположение, касательно твоих рассуждений.

Как пока видно - нет. Нифига не знаешь. Насчет болота не понял нишиша. Чему я радуюсь?

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

из чего же тебе видно?

лол, CMS. https://ru.wikipedia.org/wiki/SugarCRM

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

из этого:

И хоть тебя характеризовали как теоретика, ты даже в теории не обратил внимания на DST, хотя весь ваш сыр-бор как раз вокруг корректности выборки по времени. А раз ты ни на практике не встречался, ни в теории не учитываешь, значит просто не знаешь. Вернее не знал до сего времени.

На самом деле ты многого не знаешь, как впрочем и я, и любой другой. Все знать невозможно, да и не нужно. Для того и дискусы, чтобы заполнить некоторые пробелы.

Вот к примеру вопрос. Есть партицированная по месяцам таблица. Как сделать выборку между 1 января и 28 февраля одного года? Как это выглядит по твоей схеме?

Предполагаю что-то типа

$qb->select(...)
   ->from(...)
   ->add('where', $qb->expr()->between( 'date',  ':date_from', ':date_to')
)->setParameters(.......

так?

Ой, ну простите великодушно. :D В данном контексте что это меняет?

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

Но с партицированными таблицами я не работал, я не знаю что там может быть по производительности и нюансам составления запросов для них.

это я вообще не понимаю к чему написано, у меня же написан такой оборот

фраза вообще не предполагает, что я гуру. Эта фраза описывает мое пренебрежительное отношение к твоим навыкам в обсуждаемой теме.

не знаю, я просто обращаю внимание, что я не рассматриваю веб-приложения, так как это делаешь ты.

Рили? Охрененные логические цепочки, дядя.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Интересно почему? Да собственно не важно, сути это не меняет. Разницы все равно никакой.

Действительно, и это не суть. Суть в том, что всяческие кверибилдеры не предусматривают многих подводных камней. А они есть. И в этом коде охренительный косяк, впрочем как и с простыми операторами.

И те, кто привык юзать билдеры, считают, что это чуть ли не панацея. Раз уж доктрина (а это её синтаксис), то значит по определению должно быть всё тип-топ. И даже эксплайнами не задуряются. К тому же альтернативы то нет. Вернее можно изгольнуться на том же DQL руками попробовать исправить кикоз. Или переопределить доктриновские методы. Но вот не понятно - зачем? Ради того, чтобы эта доктрина стояла и ты мог сказать - я крут? Могу на другую СУБД перескочить или запросы модифицировать, размазав по всему приложению?

Вот в том и дело всё. С одним ты на практике не сталкивался, с другим не работал, с третьим. А пытаешься высказать пренебрежительное отношение к моим навыкам в обсуждаемой теме. Гордыня - страшный грех!

Причем здесь я? Это классификация от
killer8080

У тебя ширпотребный продукт, и совсем не важно CMS это или CRM. А значит твои предпочтения совершенно понятны. Ни кто не упрекал тебя, повторюсь. Ничего плохого в этом нет. Просто это факт и всё, не более.

Какие уж есть.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.