Код вашего сервера должен использовать UTC, поэтому вам не нужно заботиться о положении вашего сервера.Использование местного времени может привести к проблемам, потому что некоторые моменты времени не существуют или существуют дважды (скачки DST).Однако, когда ваш серверный код действует от имени пользователя, он должен учитывать настройки часового пояса этого пользователя, поэтому вам следует сначала посмотреть его.Однако это зависит от ваших точных требований.
Я бы посоветовал вам взглянуть на Joda Time , чтобы узнать о проблемах и решениях, связанных с часовыми поясами.Это библиотека Java, но, возможно, есть эквивалент в PHP или вы можете узнать из их источников.
Теперь ваши требования: вам нужно убедиться, чего именно вы хотите достичь точно .Пример: у пользователя из Лос-Анджелеса есть друг в Австралии.Когда вы уведомляете пользователя LA о дне рождения австралийца, учитывая огромную разницу во времени?Что делать с людьми, родившимися 29 февраля?Что, если пользователь LA в настоящее время находится в Токио?Я бы сказал, на этом этапе упростите вашу жизнь, потому что точность и своевременное оповещение увеличат проблемупотому что день рождения - это повторяющееся событие, а не момент времени.Вы можете сохранить время следующего уведомления в UTC, но это не так просто - продолжайте читать.
Кроме того, вам нужно сохранить часовой пояс для каждого пользователя.Эти часовые пояса также раздражают , если вам нужна точность : их смещения могут измениться, и их правила перехода на летнее время изменятся (иногда в короткие сроки).Поэтому имеет смысл хранить только TimezoneId.Это является причиной того, что денормализация «следующего времени уведомления» за год может быть проблемой.
Ваши точные требования будут определять код и структуру данных.Мой совет: рассматривать дни рождения как повторяющиеся, продолжительные события местного времени .Сохраните идентификатор часового пояса и дату (без времени!).Ваши дни рождения не «привязаны» к часовому поясу, потому что это не имеет смысла - день рождения «следует за вами», когда вы переходите в другой часовой пояс.
Имеет смысл сохранить следующее уведомление дата и время (UTC) в базе данных, поэтому ваш код поиска уведомлений прост, но имейте в виду, что вам придется обновлять их, если пользователь изменяет свой часовой пояс или правительство внезапно решит ввести DSTПравило.
Как примечание: ваш хрон должен запускаться чаще, чем ежедневно, по крайней мере, ежечасно.