Все даты должны храниться в одном и том же часовом поясе - UTC-0. Таким образом, вы можете сортировать, сравнивать, подразделять/добавлять без каких-либо преобразований.
У вас может возникнуть соблазн просто сохранить дату, учитываемую в каждом аэропорту. Итак, летя из Рейкьявика (KEF) в Афины (ATH), вы можете получить 2020-11-04 10:00 и 2020-11-04 14:00, это позволит вам отобразить необработанные данные: 10: 00 (REK) -> 14:00 (ATH), отлично. Но теперь, чтобы рассчитать продолжительность полета, вам нужно будет преобразовать одно или другое, чтобы получить разницу, потому что полет длится 6 часов, а не 4 часа. И еще сложнее: давайте теперь выведем 5 следующих рейсов. В вашей БД (базе данных) смешанные часовые пояса, поэтому вы не можете полагаться на оптимизацию БД для сортировки и ограничения результата. Вы даже сейчас не можете определить, какой рейс уже вылетел или нет, без преобразования каждой даты в базовый часовой пояс. Это позор.
Многие предприятия/организации допустили ошибку, приняв местоположение своего предприятия или сервера в качестве эталонного часового пояса. Вам следует мыслить масштабнее! Когда-нибудь вы сможете переместить свой сервер, стать международной компанией или просто захотите повторно использовать часть своего приложения или своей базы данных. Тогда часовой пояс, который вы изначально выбрали, не будет иметь абсолютно никакого смысла, и если вам придется объединиться с другой БД, он больше не будет согласованным.
Хуже того, если вы выберете часовой пояс с летним временем в качестве эталона (США, Европа и т. д.), тогда у вас возникнут ошибки в расчетах (например, приведенный выше рейс даст вам 5 или 7 часов вместо 6 при переходе на летнее время). в вашем эталонном часовом поясе во время полета).
Всемирным стандартом системы времени является UTC, он определяет каждый часовой пояс от GMT (среднее время по Гринвичу) +/- заданный временной сдвиг. Поэтому, чтобы максимизировать совместимость и избежать болезненных проблем, используйте UTC в качестве часового пояса по умолчанию для вашего приложения и сохраняйте любой момент в своей базе данных или любом другом хранилище.
Наконец, вам не нужно хранить строку часового пояса для каждой даты с фиксированным часовым поясом, вы должны применить логическое отношение/группировку в соответствии с вашими потребностями. Например, если вы хотите отправлять своим пользователям электронные письма с датами, вы не можете получить доступ к браузерам при отправке почты, поэтому вам нужно выбрать часовой пояс, вы можете использовать последний известный часовой пояс пользователя (предположим, вы обновили некоторые поле таблицы пользователей с часовым поясом браузера при входе пользователя в ваше приложение). В этом случае вам, очевидно, не нужно хранить часовой пояс для каждой сохраненной даты, вы можете просто сохранить его и повторно использовать его для каждой даты во всех электронных письмах для данного пользователя.
Вы можете проверить часовой пояс по умолчанию, выполнив функцию PHP date_default_timezone_get(). Если его нет 'UTC'ни в одной вашей среде, вам следует использовать его date_default_timezone_set('UTC')в каком-то глобальном месте, например, registerBundles() в src/Kernel.php, чтобы гарантировать, что это всегда UTC.
Источник: 1
Комментарии
Комментариев пока нет.