Comments 19
Вечная тема… И без единственного правильного решения
Была статья Заблуждения большинства программистов относительно «времени» четыре года назад.
Время мы храним в UTC. А пользователю показываем согласно актуальной (на момент просмотра!) временной зоне — митинга если offline, или пользователя если online.
При отображении из сохранённой информации можно легко востановить нужную TZ:
((localTime + (locale -> actualMeetingTz)) -> actualUtcTime;
(actualUtcTime + onlineUserTz) -> actualOnlineUserTime.
Подробнее тут (на аглиском): codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/comment-page-2/#comment-59146
И какой временной пояс вы собираетесь хранить? Или вы попросите пользователя указать еще и его?
Для митингов с указанием физической локации вытягиваем из локации, для онлайн-митингов на выбор:
- дефолтную для организации/юнита/группы
- локальную пользователя из системных настроек
- локальную пользователя по геоданным
- локальную пользователя по его настройкм
- что-то ещё
возможно с приоритетами и фолбэками. И показ пользователю с подтверждением и/или возможностью исправить
Под TZ сейчас многие понимают не TZ, а TZ Offset. Вы что понимаете?
Могут быть, да. Только в России на моей памяти несколько переходов было таких, что одна точка переходила в разные часовые пояса. Но закладываться на это сильно я бы не стал, если нет особых требований к железобетонности решения задачи своевременного уведомления о митинге через 100 лет. Проще следить за анонсами и уведомлять пользователей по типу "вы запланировали митинг 14 декабря 2119-го в часовом поясе Europe/Paris, некоторые места (список или ссылка), которые ранее входили в него, с 1 мая 2067-го в него входить не будут. Проверьте актуальность часового пояса для этого митинга.", если локация, как физическая точка или хотя бы пятно, отсутствует".
Ведь на самом деле пользователь не «планировали митинг… в часовом поясе Europe/Paris» он планировал его просто в Париже. Все остальное это костыли, которые придумываем мы, разработчики.
Сразу сказу, что онлайн-митинг — это отдельная проблема, а сейчас мы обсуждаем простую встречу в физической точке на поверхности земного шара (как у автора в задаче).
Если даже он указал нам, что планировал её именно в Париже, я бы часовой пояс вычислил на момент указания и сохранил бы отдельно. Создав параллельно процесс перевычисления при изменении границ зоны.
locale -> TZ действительно требует больших (сравнительно) затрат. Или вы что-то иное имели в виду?Не только и не столько. Вернее для оптимизации, но не вычислительных ресурсов: есть у меня гипотеза, что средствами "стандартного" SQL вычислить из локации таймзону даже на текущий момент нетривиально, мягко говоря, будет. На ЯП общего назначения это будет гораздо проще и сделать, и поддерживать в дальнейшем, особенно если хранить рядом с остальными полями, что позволит использовать простой WHERE.
Оптимизация вычресурсов: бесплатный бонус. Инвалидация — плата за удобство.
Меня эта задача заинтересовала больше в академическом плане, типа списка необходимых и достаточных данных. В этом плане часовой пояс не нужен. Но при имплементации, как вы правильно заметили, возможен вариант, когда его хранение оправдано.
Ну да, в этом плане достаточно физической точки и какой-то актуальной базы часовых поясов. По крайней мере для относительно стационарных точек на Земле. Какие-нибудь рандеву на МКС или онлайн-митинги скорее требуют прямого указания часового пояса от пользователя или попыток его автоматического определения.
tzdata и аналоги, позволяют переводить из зоны в зону хоть в прошлом, хоть в обозримом будущем. Или я неправильно понял про "вычислить"?
Дата и время: трудно, но возможно