Работа с датами

Question

Так что в основном я храню кучу событий календаря в таблице MySQL. И я храню день недели, когда они должны были произойти, а также время. Прямо сейчас время хранится как количество секунд с полуночи, рассчитанное в GMT. Но когда у меня есть люди, которые входят в систему и проверяют календарь, и они находятся в другом часовом поясе, отличном от GMT, у меня возникают проблемы с подсчетом, какие события находятся в пределах дня в их часовом поясе. Есть предложения?

Answer 1

Когда вы имеете дело с часовыми поясами, вы не хотите самостоятельно выполнять вычисления смещения, особенно если вы работаете с единицами времени, меньшими, чем 1 день. Одна простая причина: летнее время.

И MySQL, и PHP имеют множество функций даты / времени для манипулирования датами. Они знают о летнем времени и других причудах смены дат и времени. И они исправляют это чаще, чем вы, если вы попытаетесь свернуть решение вручную. По крайней мере, используйте (или создайте) объект даты, который включает часовой пояс. Функции PHP могут быть немного хитрыми и, к сожалению, не так хорошо документированы, но все возможности есть. Вы все еще можете использовать метки времени Unix в качестве своего «канонического» формата, но весь код, который работает с ним, должен знать или понимать, в каком часовом поясе он находится «в».

На прошлой работе мне приходилось иметь дело со школьным расписанием и преобразовывать этот формат (термин, неделя, день, период ...) в реальные даты и обратно. Мы создали объект, который выполнял все необходимые преобразования по требованию и кэшировал результаты. Это было усилием, но наличие функций даты PHP, которые делают все преобразования и корректировки, избавило от многих проблем с часовыми поясами и переходом на летнее время.

Еще одна оговорка с календарями: вам, возможно, придется различать часовые пояса событий и часовые пояса пользователей . И когда часовые пояса событий остаются фиксированными и когда они перемещаются вместе с пользователями. Неспособность обработать все нюансы этого является причиной, почему у календаря в Exchange / Outlook все еще есть проблемы с изменениями летнего времени. : -)

Answer 2

Вот много функций , которые могут помочь вам.

Answer 3

Используйте базу данных 'datetime datatypes и используйте базу данных' функции date / time. Функции PHP довольно ограничены, и вы должны , а не просто рассматривать время как целое число, если вы имеете дело с реальными датами. Хорошей стратегией является сохранение всех дат и времени в UTC, и тогда у вас может быть дополнительное поле для местоположения (например, смещение местного часового пояса), если это уместно. Часто, однако, это зрителей часовой пояс, который важен, а не тот, который предоставил данные (Смущенный еще?)

Answer 4

Я бы сохранил метку времени Unix для события и использовал бы функции времени в PHP для вычисления правильного отображения. Это делает данные базы данных независимыми от часового пояса, в котором вы на самом деле находитесь. Пользователь по-прежнему должен указать часовой пояс, в котором он находится.

Answer 5

Вы можете преобразовать текущую дату в их часовом поясе в GMT перед выполнением сравнения (не обязательно в MySQL, но, вероятно, вы можете использовать CONVERT_TZ для этого).

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