2013-09-27 1 views
0

Я должен сделать запрос для выборки и затем подсчитать все записи с created_at, по дате в часовом поясе:Fetch и подсчитать количество записей по дате

def total_by_date(my_date)  
    where{created_at <= my_date}.count 
end 

created_at хранится в виде timestamp в UTC в PostgreSQL, но my_date - это часовой пояс даты в Rails.

Как это можно сделать в правильном направлении, без потерь из-за изменения часового пояса, и должно должно быть created_at быть преобразовано в Date first?

+0

Я немного смущен о статье 'where'. Вызывается ли это 'total_by_date' как область видимости? Используете ли вы какие-либо драгоценные камни для запросов? –

ответ

1

Большая проблема с простым объектом ol Date заключается в том, что он не содержит информации о времени. Таким образом, в вашем запросе, который у вас есть в настоящее время, вы получите все до указанной даты, так как запрос разрешит что-то вроде WHERE created_at <= '2013-09-27'.... Один из способов, вы можете обойти эту проблему, не теряя при записи, чтобы просто добавить 1 день к объекту даты, например:

def total_by_date(my_date)  
    where{created_at <= (my_date + 1.day)}.count 
end 

В этом случае тоже вам не нужно беспокоиться о часовых поясах на всех; вы просто смотрите на часть даты.

** Редактировать **

В ответ на Ваш вопрос в комментарии:

Что касается почему + 1.day работы, подумайте о дате, как это: my_date приходит, выглядя как 2013-09-24 в запрос, но он в основном такой же, как 2013-09-24 00:00:00. Это было бы так же, как дата-время/отметка времени, установленная в полночь 24 сентября. Итак, на простом английском языке, если ваше сравнение «дайте мне все до или до полуночи 24 сентября», вы получите каждый результат, который приземляется, и существует раньше, чем это конкретное время и дата, но ничего, что произошло позднее в день 24 сентября, не появится.

Следовательно, + 1.day - та же самая «проблема» по-прежнему существует, за исключением того, что она работает в вашу пользу сейчас, потому что наш запрос теперь «что-то до или после полуночи 25 сентября».

Примечание: Технически, вы можете получить нежелательные матчи за все, что случилось быть создан ровно в полночь 25 сентября, но вы можете легко изменить ваше сравнение просто < вместо <=, чтобы решить эту проблему.

+0

Эй, Тег, спасибо за ваш ответ. Да, я забыл упомянуть Squeel здесь, так что вообще, все в порядке с самим запросом. Теперь я пытаюсь обернуть голову вокруг вещей «+ 1.day» и выяснить, почему это работает (это хорошо ... похоже ...). Не получается, почему, если у меня, например, есть '2013-09-24' как' my_date' и '2013-09-24 13: 06: 22', так как' created_at', 'my_date' будет до указанной даты. Weird. –

+1

Подумайте о такой дате: 'my_date' выходит как' 2013-09-24', но это в основном то же самое, что '2013-09-24 00: 00: 00'. Это было бы так же, как дата-время/отметка времени, установленная в полночь 24 сентября. Итак, если ваше сравнение «что-то до или до полуночи 24 сентября», вы получите каждый результат, который приземлится и существует раньше этого времени и дата, но ничего, что произошло позднее в день 24 сентября, не появится. Следовательно, '+ 1.day' - та же« проблема »все еще существует, за исключением того, что теперь это работает в вашу пользу, потому что наш запрос теперь« что-то до или после полуночи 25 сентября ». –

+0

@LeoBurt Добавлены дополнительные пояснения к ответу.Надеюсь, это поможет. –