Как группировать материалы с учетом ч/з?

Question

[Nikita Kravchenko]

Здравствуйте!
Стоит задача группировать по дате материалы (дата события). В базе как timestamp в utc.
Вот что получилось:

Но нужно учитывать часовую зону пользователя. Поэтому дата немного изменится и в какие-то дни новости сместятся и окажутся в другие дни.)
Вот что у меня получилось, но никак не могу добавить ко всему этому timezone пользователя:

return Match::select('id', 'date')
            ->orderBy('date', 'asc')
            ->get()
            ->groupBy(function($val) {return Carbon::parse($val->date)->format('m-d');});

Comments

[Дмитрий]

Добавьте в выборку unix_timestamp(date) as timestamp и по нему сортируйте

[JhaoDa]

За код скриншотами тебя ждёт отдельный котёл.

[Nikita Kravchenko]

JhaoDa, ой, даже не подумал. Исправил)

[Nikita Kravchenko]

Дмитрий, сортировать? Мне бы группировать

[Дмитрий]

Nikita Kravchenko, ну группируйте, просто ещё одно поле с другой функцией даты

[Модератор]

https://toster.ru/help/rules
3.8

Answer 1

[Immortal_pony]

В базе у вас поле типа mysql timestamp или int(11)?
В обоих случаях, примерно так:

->groupBy(\DB::raw("RIGHT(LEFT(CONVERT_TZ(`date`, '+00:00', '+10:00'), 10), 5)");

где +10:00 - это таймзона пользователя.
Если у вас unix_timestamp лежит в int(11), то перед CONVERT_TZ необходимо сделать еще FROM_UNIXTIME

Comments

[Alex Wells]

О боже, лучше бы не позорился.

[Immortal_pony]

Alex Wells, обоснуете?

[Nikita Kravchenko]

не получается

[Nikita Kravchenko]

Immortal_pony, группа отделилась, но одна и общая.

[Alex Wells]

Immortal_pony, это даже и близко не то, что хочет автор. Ему нужно выделить разные ключи, а вы делаете group by по СУБД, который к этому не имеет никакого отношения.

Кроме того, если у вас есть нужда писать ТАКОЕ (три функции, пять параметров) - значит вы что-то делаете не так.

[Immortal_pony]

Nikita Kravchenko, возможно это связано с тем что группировку вы делаете уже после get. Вот примерный код на чистом sql, который должен получиться:

SELECT 
    RIGHT(LEFT(CONVERT_TZ(`date`, '+00:00', '+10:00'), 10), 5) AS 'day',
    CONCAT('[', GROUP_CONCAT(JSON_OBJECT('id', `id`, 'date', `date`)), ']') AS 'data'
FROM 
    `news` 
GROUP BY 
    RIGHT(LEFT(CONVERT_TZ(`date`, '+00:00', '+10:00'), 10), 5)

Результат:

[Immortal_pony]

Alex Wells,

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

СУБД прекрасно это умеет. Я не виноват, что вы не в курсе.

Кроме того, если у вас есть нужда писать ТАКОЕ (три функции, пять параметров) - значит вы что-то делаете не так.

Опять из вас вкусовщина полезла или обоснуете?

[Nikita Kravchenko]

Immortal_pony, спасибо, все работает

[Alex Wells]

Immortal_pony,

обоснуете

- так что предлагаешь, писать свою велосипедную абстракцию для построения подобных конструкций по всему проекту, которая потом вылезет боком, или в стопятсот местах говнокодить одинаковый DB::raw?

СУБД прекрасно это умеет

Ах СУБД умеет! СУБД отдает данные в виде таблицы и никак иначе, следовательно единственный вариант, который прокатит - это твой говнокод выше с имитацией json'а. Я вообще в ахуе, что кому то пришла такая идея в голову. Даже не знаю, как на такое реагировать.

[Immortal_pony]

Alex Wells, я не вижу проблем в том чтобы написать гидрацию при необходмиости. Уверен, что подобные решения уже реализованы для Laravel.

это твой говнокод выше с имитацией json'а. Я вообще в ахуе, что кому то пришла такая идея в голову.

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

[Alex Wells]

Immortal_pony,

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

Ну да, почему бы и нет - покрыть весь проект raw'ами и разгребать это говно через годик :)

Это известный и вполне рабочий подход.

Да ну? Известный где, в твоих проектах? БД для этого не предназначена и не должна этим заниматся. Группировка в СУБД создана так же не для этого.

И как это не относится? Код НУЖНО писать хорошо. Примера вверху это не касается. Даже и близко. СОВСЕМ.

[Immortal_pony]

Ну да, почему бы и нет - покрыть весь проект raw'ами и разгребать это говно через годик :)

Raw именно для этого и создан - чтобы сконструировать запрос, который позволяет сделать sql, но для которого нет специальной конструкции в query builder'е. Что ж у вас со всеми инструментами-то проблема какая-то?

Это известный и вполне рабочий подход.

Да ну? Известный где, в твоих проектах?

В моих проектах в том числе. Достаточно посмотреть changelog MySQL'я - там видно, что добавляются функции для удобной работы с JSON, потому что это востребовано. По аналогичному же пути чуть раньше пошел и PostgreSQL - и там и там можно хранить json в строках, делать по нему выборки и, конечно, делать удобную агрегацию необходимых данных. Если интересно, то статьи на эту тему легко гуглятся, как и вопросы на StackOverflow

И как это не относится? Код НУЖНО писать хорошо. Примера вверху это не касается. Даже и близко. СОВСЕМ.

Если вы не знаете какого-то подхода, то это не значит что он плох. Развивайтесь.

Answer 2

[Alex Wells]

Бекенд не знает об часовой зоне пользователя. От слова "совсем". Ему приходит UTC, он отдает UTC. Хочешь смещение - делай групировку на фронте (где она и должна быть, кстати).

Comments

[Immortal_pony]

А что мешает передать backend'у таймзону пользователя?
Кому группировка "должна" быть на фронте?

[Alex Wells]

Immortal_pony, мешают стандарты, принятые в разработке. АПИ не должно быть привязано ни к какому юзеру, и, следовательно, никакой таймзоны он не знает. А что если АПИ публичное? В какой таймзоне отдавать? UTC? А что если есть публичная форма (без авторизации), с полем типа дейттайм? В каком формате отправлять?

Стандартизация. Везде UTC. Потому что так проще всем.

А на фронте показывай себе что хочешь. Хочешь показывать неавторизированному в его локальной таймзоне - да пожалуйста, momentjs легко угадает твою таймзону и прибавит нужное время. Тоже самое и с формой. При этом код для авторизированных и неавторизированных юзеров не отличается СОВСЕМ.

Эта группировка там лишь для того, что бы на фронте вывести данные в таком формате. Уже понял проблему? Бекенд не волнует, как там выводит данные фронт. Он вообще не знает о фронте. Максимально, что знает бекенд о фронте - это то, какой минимальный набор полей нужен на каждую модель данных. ВСЕ. Больше никаких дополнительных "спарсенных" полей, "красивых" дат или, боже упаси, группировок по ключам. Фронту нужно выводить так - так пусть этим и занимается, при чем тут бэк то?

[Immortal_pony]

мешают стандарты, принятые в разработке.

Какие стандарты? Кем принятые? Имена, явки, фамилии, ссылки?

АПИ не должно быть привязано ни к какому юзеру, и, следовательно, никакой таймзоны он не знает.

Каким образом одно следует из другого? API может быть не привязано к пользователю и при этом принимать таймзону как параметр. Как и любой другой параметр.

Стандартизация. Везде UTC. Потому что так проще всем.

Опять какие-то стандарты, которые вы придумали для самого себя?

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

[kingcomp_ru]

Immortal_pony, имейте уважение к чужому времени. Вам дали наводку, поискать могли и сами.
В сообществах полно информации почему не стоит хранить часовые пояса в БД.
The Problem with Time & Timezones - Computerphile
Что должен знать о времени каждый программист
и т.д.

Всегда могут быть исключения. Оцените как часто придется возвращать время с timezone. Если изредка или малому кругу лиц, то засорять ответ для остальных не стоит. Или повсеместно? — тогда стоит.

Но всегда храните в UTC. Пусть даже копию. =)

[Nikita Kravchenko]

kingcomp_ru, так время так и так хранится в utc. Выводится уже целовекопончтным видом, преобразованием в нужную часовую зону и распределением по группам/дням.

[Alex Wells]

Immortal_pony,

при этом принимать таймзону как параметр

- может. Вопрос - нахрена?

Где ответ на вопрос с публичным АПИ? Будете к каждому запросу лепить таймзону как параметр? А как вебсокетам знать, в какой таймзоне вы хотите ответ?

Еще вопрос: как будете выводить дату, если по ТЗ нужно вывести ее в двух часовых зонах - локальной и по Moscow? Ваш лучший вариант - спарсить дату в указанной таймзоне momentjs'ом, предварительно указав таймзону, и засетать Moscow. Консистентность? Не, не слышал.

Еще вопрос, который я уже задавал: каким образом будете фиксить неправильное время на ПК клиента? Вы можете гарантировать, что у каждого, кто пользуется вашим фронтом, будет верное время? Нет? Каким образом будете компенсировать? Добавлять ВТОРОЙ параметр, помимо таймзоны, типа offset и указывать кол-во часов-минут?

Это негласный стандарт, конечно же. Такой же, как и ХРАНЕНИЕ дат в UTC.

Разделяйте ответственность между фронтом и беком.

[Immortal_pony]

kingcomp_ru,

имейте уважение к чужому времени. Вам дали наводку, поискать могли и сами.
В сообществах полно информации почему не стоит хранить часовые пояса в БД.
The Problem with Time & Timezones - Computerphile
Что должен знать о времени каждый программист

По этим ссылкам нет никакой информации о том что сервер не может отдавать данные с учетом таймзоны, если она указана как один из параметров. Именно этот случай мы и рассматриваем.

Alex Wells,

при этом принимать таймзону как параметр

- может. Вопрос - нахрена?

Чтобы не проводить операции фильтрации и группировки на клиенте, конечно.
Вон, в примере, необходимо сгруппировать данные по дате с учетом таймзоны клиента. Предположим, а таблице с данными 100000 записей. Их все на клиент перекинуть и там группировать?

Где ответ на вопрос с публичным АПИ? Будете к каждому запросу лепить таймзону как параметр?

Да, конечно. Если API endpoint позволяет менять результаты выборки в зависимости от таймзоны, этот параметр следует принимать. Можно сделать его опциональным и по умолчанию использовать таймзону сервера или UTC. В любом случае это должно быть указано в документации.

Еще вопрос: как будете выводить дату, если по ТЗ нужно вывести ее в двух часовых зонах - локальной и по Moscow? Ваш лучший вариант - спарсить дату в указанной таймзоне momentjs'ом, предварительно указав таймзону, и засетать Moscow. Консистентность? Не, не слышал.

Я не понимаю вашей проблемы. Что и куда выводить? Что и откуда парсить? Что такое "засетать"?
Если от сервера вам надо получить две даты какого-то события - одну в UTC, а одну в часовом поясе пользователя, то сервер их и отдаст.

Еще вопрос, который я уже задавал: каким образом будете фиксить неправильное время на ПК клиента? Вы можете гарантировать, что у каждого, кто пользуется вашим фронтом, будет верное время? Нет? Каким образом будете компенсировать? Добавлять ВТОРОЙ параметр, помимо таймзоны, типа offset и указывать кол-во часов-минут?

Не совсем понимаю проблему. Клиент указывает в качестве параметра таймзону и в зависимости от нее изменяется выборка на сервере. Если нет уверенности, что таймзона поддерживается сервером, то можно указывать значение offset прямо в параметре timezone. mysql-функция CONVERT_TZ прекрасно умеет работать с таким способом указания таймзоны.

Это негласный стандарт, конечно же. Такой же, как и ХРАНЕНИЕ дат в UTC.

Ах негласный. Ну тогда все понятно, конечно.

[Alex Wells]

Вон, в примере, необходимо сгруппировать данные по дате с учетом таймзоны клиента. Предположим, а таблице с данными 100000 записей. Их все на клиент перекинуть и там группировать?

Вернется то 100 тысяч записей что с группировкой, что без, и перекинуть нужно будет сто тысяч в обеих случаях - в чем разница?

Да, конечно.

Извини, но это хуйня какая-то.

то сервер их и отдаст.

Лол. То есть отдавать одни и те же данные дважды, просто потому что фронту лень работать с датами? От бека идет минимальный нужный набор данных. Данные от бека должны быть МАКСИМАЛЬНО независимыми от фронта.

то можно указывать значение offset прямо в параметре timezone

Мда. А давайте ка придумаем велосипед, которым ОЧЕНЬ УДОБНО пользоватся, а так же забудем о консистентности (в каждом запросе одни и те же данные могут означать разные вещи - что есть пиздец), ради того, что бы.. что бы что? Я так и не понял, нахрена так делать.

Ах негласный. Ну тогда все понятно, конечно.

Именно негласный. Точно такой же, как и хранение дат в UTC в базе, а не в чем-то другом. Или использование utf8mb4 вместо utf8/любой другой в mysql. Или расстановка foreign ключей. Или тайп-хинтинг + var аннотации. Продолжать?

[Immortal_pony]

Извини, но это хуйня какая-то.

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

он, в примере, необходимо сгруппировать данные по дате с учетом таймзоны клиента. Предположим, а таблице с данными 100000 записей. Их все на клиент перекинуть и там группировать?

Вернется то 100 тысяч записей что с группировкой, что без, и перекинуть нужно будет сто тысяч в обеих случаях - в чем разница?

Разница в том что при серверной группировке нет необходимости отдавать все 100000 записей клиенту. Достаточно отдать одну страницу - например, сгруппированные записи за 20 дней.

Лол. То есть отдавать одни и те же данные дважды, просто потому что фронту лень работать с датами? От бека идет минимальный нужный набор данных. Данные от бека должны быть МАКСИМАЛЬНО независимыми от фронта.

Опять данные кому-то должны, эх. Задача в том, чтобы у пользователя максимально быстро открылся сайт. Плюс предварительной обработки данных на сервере в том, что, во-первых, пользователю не придется скачивать js-код, который будет заниматься обработкой на его стороне, а, во-вторых, клиентскому устройству не придется этот код исполнять.

Мда. А давайте ка придумаем велосипед, которым ОЧЕНЬ УДОБНО пользоватся, а так же забудем о консистентности (в каждом запросе одни и те же данные могут означать разные вещи - что есть пиздец), ради того, что бы.. что бы что? Я так и не понял, нахрена так делать.

Это опять какая-то ваша вкусовщина. По данному параметру в запросе можно будет определить часовое смещение пользователя. И если сервер принимает его в нескольких форматах - это нормально и это тоже абсолютно обычный подход. Вам примеров?

Именно негласный. Точно такой же, как и хранение дат в UTC в базе, а не в чем-то другом. Или использование utf8mb4 вместо utf8/любой другой в mysql. Или расстановка foreign ключей. Или тайп-хинтинг + var аннотации. Продолжать?

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

использование utf8mb4 вместо utf8/любой другой в mysql.

Если не планируется мультиязычности, то никакой разницы.

расстановка foreign ключей

Вредный overhead на мелких проектах. Не нужен.

тайп-хинтинг + var аннотации

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

[Alex Wells]

Разница в том что при серверной группировке нет необходимости отдавать все 100000 записей клиенту. Достаточно отдать одну страницу - например, сгруппированные записи за 20 дней.

Делаешь orderBy + where за последние двадцять дней. То, что ты бы делал и без твоей говно-групировки, только быстрее и проще.

Опять данные кому-то должны, эх. Задача в том, чтобы у пользователя максимально быстро открылся сайт. Плюс предварительной обработки данных на сервере в том, что, во-первых, пользователю не придется скачивать js-код, который будет заниматься обработкой на его стороне, а, во-вторых, клиентскому устройству не придется этот код исполнять.

Что за бред? Человек делает АПИ, а не монолит с рендерингом на сервере. У него приложение - SPA, которое само по себе АПРИОРИ JS. И momentjs, весом в 22кб gzip, в сравнении с всем фронтовым приложением не весит нихрена.

можно будет определить часовое смещение пользователя

Можно. Вопрос - нахрена? Зачем делать эту систему с параметром, когда это УЖЕ готово в momentjs?

Еще вопрос: что если тебе нужно в одном запросе отправить две даты: одна от юзера, а вторая - с какого-нить гуглосервиса в UTC. Будешь делать на каждую дату по параметру? Или конвертить гуглодату по оффсету в юзерскую дату, а потом на беке снова назад? Или второй параметр ignore?

Приведу примеры, когда эти рекомендации спокойно можно игнорировать. Или даже нужно.

Давай.

Если не планируется мультиязычности, то никакой разницы.

... future proofing - не, не слышал.

Вредный overhead на мелких проектах. Не нужен.

Конечно не нужен. Кому нужны индексы? Кому нужна гарантия целостности данных? Та зачем, ведь какому-то программисту Петькину из Москвы лень было написать пять строчек.

Аннотации для переменных при наличии тайпхинтинга

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

[Immortal_pony]

Делаешь orderBy + where за последние двадцять дней. То, что ты бы делал и без твоей говно-групировки, только быстрее и проще.

... и мы получаем 15 элементов после группировки на клиенте вместо 20, потому что 5 дней не было никаких событий. Проблема в том, что клиент не знает количество элементов после группировки пока не сгруппирует.

Что за бред? Человек делает АПИ, а не монолит с рендерингом на сервере. У него приложение - SPA, которое само по себе АПРИОРИ JS. И momentjs, весом в 22кб gzip, в сравнении с всем фронтовым приложением не весит нихрена.

Какая разница, SPA это или нет? Из таких вот моментов и раздувается приложение на ровном месте.
И перенос подобной логики на сервер поможет с этим справиться.

Еще вопрос: что если тебе нужно в одном запросе отправить две даты: одна от юзера, а вторая - с какого-нить гуглосервиса в UTC. Будешь делать на каждую дату по параметру? Или конвертить гуглодату по оффсету в юзерскую дату, а потом на беке снова назад? Или второй параметр ignore?

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

future proofing - не, не слышал

Слышал про преждевременную оптимизацию. Очень вредная штука.

Конечно не нужен. Кому нужны индексы? Кому нужна гарантия целостности данных?

На мелких проектах - никому. Пустая трата денег заказчика.

[Alex Wells]

... и мы получаем 15 элементов после группировки на клиенте вместо 20, потому что 5 дней не было никаких событий. Проблема в том, что клиент не знает количество элементов после группировки пока не сгруппирует.

Ок, ты прав, я затупил.

Какая разница, SPA это или нет? Из таких вот моментов и раздувается приложение на ровном месте.
И перенос подобной логики на сервер поможет с этим справиться.

Разница в том, что лишних 22кб не сыграют никакой роли.

Пусть раздувается. SPA - это приложение, клиент, а не просто рендерер.

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

Я уже привел пример. Жду решение.

Слышал про преждевременную оптимизацию. Очень вредная штука.

Где тут оптимизация?

На мелких проектах - никому. Пустая трата денег заказчика.

foreign ключи не стоят денег в рамках всего проекта. И... "никому"? Ну, ясно, на этом можем закончить.