20 февраля 2019 в 3:48
Данный модуль мне нужен для вычисления разности между датами во Views.
На тестовом сайте с тестовыми данными модуль работает хорошо, а на рабочем выводит некорректные значения, хотя настройки полей идентичны на обоих сайтах. Подскажите, в чем может быть причина?
22 февраля 2019 в 10:53
Никаких дополнительных модулей не надо, всё в ядре:
PS Заменил скриншот на русский. Никогда не переключаю админку на русский и не понимаю как другие могут без слёз смотреть на "Cредство форматирования: Собственная" и прочую подобную галиматью и что-то даже понимать 
PPS Вернул английский скриншот и оставил оба, чтобы было понятно о чём я
Содержимое сайта публикуется на условиях CreativeCommons Attribution-ShareAlike 3.0 или более поздней версии. Программные коды в тексте статей — на условиях GNU GPL v2 или более поздней версии.
Документация по совместной работе с репозиторием drupal.ru – https://docs.drupal.ru/code
Drupal – торговая марка Дриса Бёйтарта
Поддерживать инфраструктуру Drupal.ru нам помогает компания ДАЛЕЕ
Комментарии
Если Вы используете даты то надо понимать что например на сервере может быть другой часовой пояс и при вычислении разницы на датах можно получить разные значения например при использовании UNIX_TIMESTAMP
см. http://qaru.site/questions/16013257/mysql-seconds-difference-unexpected-...
Выяснилось, что если оперировать датами "создание" и "изменение", то проблем не возникает. А если оперировать другими датами сущности, то появляется число вроде этого "1546323030". Может быть дело в типе данных MySQL?
Подскажите, как включить отображение SQL запроса в админке Views? в phpmyadmin не могу найти таблицы с данными представления.
/admin/structure/views/settings
admin/structure/views/settings ->НАСТРОЙКИ АВТОМАТИЧЕСКОГО ПРЕДПРОСМОТРА -> Показывать SQL-запрос
Кстати это
Конвертивание эпохи Unix в человекопонятную дату(human readable date)
1546323030
GMT: Tue, 01 Jan 2019 06:10:30 GMT
Ваша временная зона: 01.01.2019, 9:10:30
Если подобное число в секундах появляется при вычитании дат, то похоже что одна из ваших дат не определена, и вы по сути вычисляете разницу между датой в 2019 году и 1 января 1970 года.
Оказалось, что модуль ECK, при помощи которого я сделал сущности, создает в MySQL столбцы с типом int(11) для полей "дата создания" и "дата редактирования" сущности, а для остальных столбцов содержащих дату тип varchar(20) хранящих дату в формате "2019-02-05".
Получается, что проще научится программно создавать сущности, чем зацикливаться на решение проблем связанных с конвертированием дат.
А что у вас там за сущности такие, чем обычные ноды не устраивают?
Пытаюсь сделать сайт для облегчения своей рутинной работы на предприятии. Для этого мне нужен инструмент облегчающий ввод, вывод, формирование и аналитику данных из MySQL. Данные имеют табличный вид, скриншот прилагаю.
У меня есть опыт работы с hook_menu() + theme() https://powerliftingrating.ru/athlete/162 , но спустя 3 года вялотекущей разработки, понял что иду не той дорогой... Поэтому решил познакомится с сущностями.
Я догадываюсь, что при помощи добавления полей в типы материалов можно реализовать данную задачу, однако не стал в это вникать, так как во всех статьях что мне попадались описывалось процедура создания сущностей.
Буду рад любым советам от форумчан!
Мне почему-то тоже так кажется, хотя не владея деталями Вашей "рутинной работы" невозможно сказать наверняка.
А при каких обстоятельствах эти статьи Вам попадались? Мне например ни одной такой не попалось, возможно потому что я их специально никогда не искал.
Я бы попробовал сделать на обычных нодах и типах материалов. Если есть сомнения в чем-то конкретном - напишите, разберемся.
Работать с node оказалось значительнее приятней.
Поисковые запросы не помню, помню что искал информацию на тему как сделать кастомный модуль сделанный на hook_menu() доступным для Views и /admin/content.
Мне кажется, Вы как-то методологически неправильно Друпал изучаете. Вместо того, чтобы прочесть какой-нибудь самый простой туториал где с самого нуля объясняются самые базовые вещи, или даже просто полазить по административному меню и посмотреть что там можно сделать, Вы начитались статей на очень сложные темы, которые не каждому среднему Друпалеру нужны и интересны, не то что начинающему. Я, например, только от Вас узнал про модуль ECK, кастомные сущности и про "кастомный модуль сделанный на hook_menu()", что мне совершенно не мешало писать собственные модули безо всяких hook_menu, решающие иногда довольно непростые задачи. Попробуйте сделать шаг назад и методично освоить азы.
Согласен.
Сомнений не осталось, жалею что сразу не познакомился с node.
Однако в node проявилась та же проблема что и при создании entity через ECK
Как сделать чтобы дата из поля типа "дата" записывалась в MySQL в формате UNIX?
Мне в голову приходит, что на стороне MySQL нужно сделать триггер который будет конвертировать дату. Но опасаюсь, что в будущем это может вызвать проблемы... да и с триггерами знаком заочно без практического опыта.
В общем, вот что нужно сделать:
1. Выкинуть модуль Simple Math Field за ненадобностью.
2. Вывести оба поля дат в нужное View форматтером Custom и форматом U.
3. Первое поле скрыть.
4. Второе переписать через rewrite results следующим текстом:
{{ (((field_date2|trim)-(field_date1|trim))/(60*60*24))|round }}Если оба поля чисто даты без времени, то round можно выкинуть.
Отличное решение, но я бы сделал через контроллер поля, чтобы не трогать twig
А я и не предлагаю трогать шаблоны, этот текст вводится прямо в настройки поля Views. Не все знают, что Rewrite results и Global: Custom text поддерживают практически полный синтаксис twig.
Спасибо за разъяснения, всем полезна полная инструкция по решению проблемы.
Я застрял на 2-м шаге.
Речь идет о модуле Custom Formatters? Если да, то после установки у меня не появилось никаких дополнительных настроек ни во Views, ни в настройках типа материла.
Нет он имел ввиду "Формат даты" admin/config/regional/date-time
Никаких дополнительных модулей не надо, всё в ядре:
PS Заменил скриншот на русский. Никогда не переключаю админку на русский и не понимаю как другие могут без слёз смотреть на "Cредство форматирования: Собственная" и прочую подобную галиматью и что-то даже понимать
PPS Вернул английский скриншот и оставил оба, чтобы было понятно о чём я
Получилось! Благодарю!!!
Надо бы переотметить решение на это.
Переотметил.
Чем Вас не устраивает форматISO 8601?
Тем что не могу вычислить во Views с помощью модуля Simple Math Field разность дат. Модуль Simple Math Field не может производить арифметические операция с датами формата ISO.
Почему-то Drupal хранит дату создания node в формате UNIX а дату введенную в пользовательское поле в формате ISO.
Вам надо работать с датами в одном формате и лучше в ISO, если Simple Math Field этого не умеет, поищите другой модуль или напишите свой конроллер поля для views