Комментарии 48
Это типа:
— Я думаю «вот так». Кто думает также — давайте дружить!
Так что ли?
del
С часовыми поясами всё просто: всё, что лежит на сервере, уходит на сервер и приходит с сервера — UTC, всё, что отображается на клиенте — согласно часового пояса из профиля пользователя. Это красиво.
Особенно это будет красиво, когда пользователь, находящийся в Москве, будет смотреть время концерта, проходящего в Сиэттле.
А в чём проблема? Если его интересует время концерта в Сиэтле, то пусть выставит в профиле часовой пояс Сиэтла (GMT-7). А находится при этом он может где угодно. Хоть в Москве, хоть в Магадане.
Проблема в том, что он на одной странице просматривает расписание всего американского тура, у которого есть концерты и в Сиэттле, и в Хьюстоне, и в Бостоне. И пользователь, очевидно, хочет видеть все концерты по местному времени, а не по какому-то одному.
Вовсе не очевидно, про Бостон и весь американский тур в вашем предыдущем комментарии ничего не было. В новой формулировке задача требует подстановку локального времени соответствующей позиции расписания. А где вы это будете делать — на сервере, клиенте или так и хранить в БД или ещё каком месте, то ваше дело (вернее, зависит от других условий, здесь не опубликованных; можно много разных вариантов напридумывать).
Вот видите, коллега, у вас в голове тоже мысли строем ходят, а как в слова их начали выражать, так сразу ясность и теряется. "Всё, что может быть понято неправильно, будет понято неправильно" (с) Майерсов закон письменной речи.
А где вы это будете делать — на сервере, клиенте или так и хранить в БД или ещё каком месте, то ваше дело
Что, собственно, верно для любой задачи, касающейся работы со временем. О чем и речь...
Вот я и говорю, что красиво — хранить в UTC и преобразовывать в тот формат, который требуется пользователю. Но можно хранить и в любом другом виде, хоть в JPEG'ах. Красиво — это значит, что такой подход решает больше проблем, чем создаёт.
Вот я и говорю, что красиво — хранить в UTC и преобразовывать в тот формат, который требуется пользователю. [...] Красиво — это значит, что такой подход решает больше проблем, чем создаёт.
Для задачи, которая описана выше, решение "хранить в виде полной даты-времени со смещением" решает больше проблем, и не создает дополнительных.
(оба они не решают вопроса "что делать со внезапной сменой поясного времени", но это отдельный вопрос, и он с бизнеса начинается)
Коллега, ваше решение замечательно подходит к сформулированной вами же проблеме. Только причём здесь мой пункт "Локализация"? Или вы за то, чтобы всегда использовать полную дату-время со смещением? Это вряд ли. Вам не нравится моё предложение использовать UTC для даты-времени в базе? Возьмите за базис Московское время.
Я в ответ могу только сказать, что ваше предложение использовать дату-время со смещением для глобального приложения мне также не нравится. Особенно, если нужно визуально сравнивать две даты в сырых данных (из базы или из логов). Зачем хранить различные смещения, если всё равно одни и те же данные нужно приводить к различым видам, задаваемым различными пользователями? Вы что, сами в логах не копаетесь?
А так-то на бизнес можно всё свалить — дьявол кроется в деталях и всё такое.
Только причём здесь мой пункт "Локализация"?
Понятия не имею, я его не упоминал.
Или вы за то, чтобы всегда использовать полную дату-время со смещением?
Я за то, чтобы использовать ту запись времени, которая подходит к задаче.
Возьмите за базис Московское время.
Это ничем не лучше.
Особенно, если нужно визуально сравнивать две даты в сырых данных (из базы или из логов)
В данном случае — не нужно.
Зачем хранить различные смещения
Потому что их все равно надо хранить, вопрос только в том, где и в каком виде вы будете это делать.
Вы что, сами в логах не копаетесь?
Копаюсь.
Понятия не имею, я его не упоминал.
Так назывался пункт обсуждаемой нами публикации, в котором я писал про UTC-время, которое вызвало вашу реакцию в виде:
Особенно это будет красиво, когда пользователь, находящийся в Москве, будет смотреть время концерта, проходящего в Сиэттле.
Я понимаю, что вы выпали из контекста (вернее, создали свой), поэтому и вернул вас к истокам. Если хотите обсудить преимущества/недостатки использования даты-время со смещением перед другими вариантами — можете сами написать об этом статью. Я бы предпочёл, чтобы вы всё-таки комментировали мою публикацию, а не забавные случаи из своей практики, слабо касающиеся поднятой темы.
По остальным пунктам вашей реплики мне сказать нечего — либо согласен, либо верю на слово.
Я, в общем-то, вашу публикацию и комментирую. Тема ее подана как "какое web-приложение на данный момент может считаться красивым". Заинтересовавший меня раздел начинается словами "Есть две вещи, которые меня особенно волнуют при разработке web-приложений — это мультиязычный интерфейс и часовые пояса". "A man after my own heart," подумал я (и мне совершенно все равно, что этот раздел называется "локализация", в конце концов, откуда я знаю, что вы понимаете под локализацией, определения-то вы не даете). А дальше там дается откровение: "с часовыми поясами всё просто: всё, что лежит на сервере, уходит на сервер и приходит с сервера — UTC, всё, что отображается на клиенте — согласно часового пояса из профиля пользователя". Без оговорок. Вот я и решил вам показать, что именно получится, если следовать этому конкретному пункту вашего "красиво".
Понятно :) Мне надо было бы описать класс задач, для которых приемлема моя рекомендация, да?
Ну что ж, описываю. "Во всех случаях, когда непонятно, как обрабатывать дату-время, делайте так: всё, что лежит на сервере, уходит на сервер и приходит с сервера — UTC, всё, что отображается на клиенте — согласно часового пояса из профиля пользователя. Это красиво."
Исправления внёс. Надеюсь, теперь ваше чувство прекрасного удовлетворено?
Неа, ничего не изменилось. Человеку, который раньше с таким не сталкивался, будет непонятно, он сделает по-вашему, и получит описанные проблемы.
Надо просто принять: часовые пояса — это не просто.
Как там говорил Архимед: "Дайте мне точку опоры и я переверну Землю!". Упростите немного себе жизнь — опирайтесь на UTC (оговорка: где можно или где непонятно).
Упростите немного себе жизнь — опирайтесь на UTC (оговорка: где можно или где непонятно).
Это называется "выбрасывать информацию", что, в свою очередь, чаще вредно, чем полезно.
Ну что ж, ваш опыт говорит о том, что во всех непонятных случаях используй дату-время со смещением, мой — используй UTC. Кстати, а в каком виде в базе хранится дата-время со смещением?
Кстати, а в каком виде в базе хранится дата-время со смещением?
datetimeoffset
Это для MS SQL. А для MySQL или Postgres'а?
Для Postgres, насколько я понимаю, timestamp with time zone. Для MySQL не знаю, мне с ним работать не приходилось.
Насколько мне известно, нет в MySQL возможности сохранения временной зоны в типе DATETIME/TIMESTAMP. И насколько я понял, MS SQL и Postgres сохраняют по факту дату-время в UTC с дополнительным сохранением временной зоны:
MS SQL: The data is stored in the database and processed, compared, sorted, and indexed in the server as in UTC.
Postgres: For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT).
Так что мои рекомендации "UTC на сервере" выполняются на гораздо более низком уровне, чем я представлял ;)
А вот это уже не важно: они могут завтра поменять это хранение на любое другое, и поведение не будет нарушено.
А не могли бы вы привести причину, по которой им завтра понадобится поменять то, что есть (UTC), на что-то другое? Может всё-таки есть некоторая важность того, что остановились именно UTC?
А не могли бы вы привести причину, по которой им завтра понадобится поменять то, что есть (UTC), на что-то другое?
Неа, чужая голова — потемки.
В таком случае не множьте сущности без необходимости. Остановились на UTC и причин для смена позиции на горизонте не наблюдается. А вы говорите — не важно. Стабильность — это важно. Способствует долгосрочному планированию.
А вы говорите — не важно.
Да, именно так.
Стабильность — это важно.
Так вот, стабилен внешний интерфейс, в котором сказано, что я пишу таймстемпы, указав их часовой пояс, и получаю их обратно в том же виде. И это, действительно, важно. А все остальное — детали реализации, и они не важны (пока, как обычно, абстракция не начнет течь).
Есть много нюансов. Для событий, привязанных к географии, часто лучше хранить локальное время в локации и локацию. Ещё вопрос какую локацию хранить в, например, CRM, фиксируя обращение клиента с Камчатки в колл-центре в Нижнем. Особенно для юридических претензий.
фиксируя обращение клиента с Камчатки
А каким образом вы узнаёте, что клиент с Камчатки? GeoIP? Определение местоположения по IP-адресу — та ещё затея. Или есть способ узнать координаты мобильного устройства из браузера?
Разные варианты есть. Не говоря о том, что если человек заключил договор с компании в её камчатском филиале, много лет платил там и пользовался всеми услугами там, и обратился на федеральную линию поддержки по вопросу не связанном с роумингом, то очень вероятно, что он до сих пор там и находится.
Понятно. Способа определить координаты мобильного устройства из браузера нет.
Есть. Требуют явного разрешения пользователя.
Можете скинуть ссылку на описание технологии? Спасибо.
Супер! Ещё раз спасибо! Я смотрел по спецификациям Web APIs, а это, оказывается, интерфейс навигатора.
А каково ваше решение описанной проблемы?
Вот, ещё одно удачное решение для сформулированной самим собой проблемы, которую коллега lair либо пропустил, либо не считает за проблему:
Для задачи, которая описана выше, решение "хранить в виде полной даты-времени со смещением" решает больше проблем, и не создает дополнительных.
Полифиллы и транспайлеры — это красиво! Лёгким движением ~~руки брюки ~~ несколькими строками даже не кода, а конфигов старый браузер превращается в новый — красота :) А главная красота, что разработчикам гораздо позднее теперь приходится поднимать планку используемых браузеров, если хотят использовать новые фичи (читай — ускорить разработку или принести качественные улучшения в UX), а значит меньше пользователей получат что-то вроде "ваш браузер не поддерживается — обновитесь". Красота!
P.S. Поддержка .map файлов даст вам возможность смотреть исходный код в браузере причём не только JS и CSS.
Красота в глазах смотрящего