Хранение элементов в массиве по дате в PHP

Question

Я работаю над программой php, которая должна хранить много объектов "Event" в массиве. Каждое мероприятие имеет дату исполнения, и я должен быть в состоянии легко получить эти события к тому дню. В любой день может быть несколько событий.

Я думал об использовании даты в стиле MySQL в качестве ключа, например, $ array ["year-month-day"], но это грязно. Я также пробовал $ array [year] [month] [day], но затем я получаю 4d массив, который мне тоже кажется грязным.

У меня такой вопрос: кто-нибудь нашел хороший способ хранения объектов по времени, как это, и если да, то как ты это сделал?

Answer 1

Что не так с $array['2009-08-20'][0], $array['2009-08-20'][1] и так далее? Это не кажется "грязным", учитывая структуру данных, которые вы надеетесь представить.

Если вы хотите также получать доступ к событиям по годам и месяцам, описанная вами структура 4D может иметь больше смысла (или совершенно другую структуру), но когда «день» является вашей основной организацией, используйте простую (и человеческую) -читаемо) отображение дат, как вы описали для индекса массива.

Answer 2

Вместо этого закодировать дату как день года? (т.е. 1-365 или 0-364, если вы предпочитаете)

Если у вас есть значение времени (из strtotime () или любого другого), вы можете легко получить день года, используя date('z', $time), который возвращает значение от 0 до 365 (365 для високосного дня).

Затем вы можете использовать что-то вроде $ events [year] [day] [index], что уменьшает ваше вложение на один уровень - честно говоря, вложение - это не «дьявол» или что-то еще, если оно не идет далеко.

Answer 3

Сохранение массива с ключом по времени Unix в 12:00:00 в этот день. Этот массив будет содержать все события за этот день.

Легко конвертировать между временем Unix и читаемыми человеком датами, используя функции strtotime (), time () и date () в PHP.

Answer 4

Вы можете использовать отметку времени . Обратите внимание, что в любой системе, использующей 32-разрядное целое число со знаком в качестве основного типа метки времени, ваше приложение будет страдать от проблемы год 2038 .