Вопрос по localization, internationalization, globalization, timezone – Обработка часовых поясов в хранилище?

20

Хранить все в GMT?

Сохранить все так, как было введено со встроенным смещением?

Делать математику каждый раз, когда вы делаете?

Отобразить относительное время & quot; 1 мин. Назад & quot ;?

Ваш Ответ

12   ответов
5

Джош совершенно прав выше, но у меня есть одно тонкое предостережение, чтобы объяснить. Это случай без правильного ответа относительно будущих событий и часовых поясов.

Рассмотрим случай повторной встречи. Это происходит в GMT 0000 (для простоты), что составляет 1200 NZST (стандартное время Новой Зеландии) и 1000 AEST в Сиднее, Австралия.

Когда переход на летнее время вступает в силу в одной зоне, что должно произойти с назначением? Если это:

1a. Если изменение TZ находится в зоне     назначение "владелец" (кто     забронировал его) затем попытка остаться на     такое же время на столе (например, 10:00 утра)?
 1б. Если     Смена ТЗ в одном из других     зоны участников встречи, то нет     менять

Последствия: оно движется для     все остальные, неожиданно, из-за     владельцы ТЗ меняются, но остаются     "Встреча в 10 утра" насколько     владелец обеспокоен.

& APOS; 2. Как указано выше, но в обратном порядке.

Последствия: он переносится для владельца собрания (собрание в 10 часов утра становится собранием в 9 часов утра, или v / v), что может быть ожидаемым, но неудобным. Он остается в то же время настольных часов для других участников, пока они не пройдут через свой собственный переход TZ.

Ни один не идеален. Рассмотрим случай двух встреч, один из которых забронирован Лицом А в 10:00 по местному времени, а другой забронирован Лицом Б с Лицом А в качестве посетителя в 9:00. Если человек A и человек B находятся в разных TZ, то изменение DST может легко привести к двойному бронированию.

Если ваш ум немного согнут в этой точке, тогда я вполне понимаю.

Смысл этого примера в том, что для правильного выполнения любого из этих способов поведения вам необходимо знать не только версию местного времени в формате UTC, но и TZ (а не смещение), в котором находился владелец, когда они его забронировали. В противном случае у вас нет другого выбора, кроме как выбрать вариант 2, молча, даже не сообщая никому, что все изменилось с момента времени по Гринвичу, не меняются, а меняется только презентация ... верно? (нет, это ловушка, презентация имеет значение, когда ваша встреча в 10 утра проходит сама по себе)

Я должен поблагодарить моего коллегу и друга Джейсона Поллока за это понимание. Читатьего взгляд здесьи последующее обсуждениеiCal и VTIMEZONE Вот.

Outlook Mobile запутывается именно из-за этой ошибки в поведении. Встречи по телефону меняются, когда я меняю активную зону.
@devstuff - Перемещение встреч при выборе другого часового пояса не соответствует описанию. Описывается, что сам часовой пояс изменился (из-за законодательных изменений в летнем времени) и, следовательно, часовой пояс, в котором первоначально были описаны данные, больше не существует. то есть времена изменились в одном часовом поясе.
0

Всегда храните в GMT (или UTC). Оттуда это легко преобразовать в любое значение местного часового пояса.

13

Ответ, как всегда, «зависит».

Это зависит от того, что вы описываете с течением времени, и как данные были предоставлены вам. Ключом к решению о том, как хранить значения времени, является принятие решения о том, теряете ли вы информацию, удаляя часовой пояс, а также не удивляя своих пользователей.

Хранение данных в UTC time_t дает определенные преимущества - это единственное целое число, позволяющее быстро сортировать и легко хранить.

Я вижу проблему как разбитую на определенные области:

  1. Historical Data
  2. Future, Short Term Data
  3. Future, Long Term Data

Со следующими подклассами на каждом:

  1. System Provided
  2. User Provided

Давайте посмотрим на них по одному.

System ProvidedЯ бы порекомендовал запускать системы в UTC, тогда вы избежите проблемы с часовым поясом, и опять же, никакой потери информации не будет (это всегда UTC).

Historical DataЭто такие вещи, как файлы системного журнала, статистика процесса, трассировка, даты / время комментирования и т. Д. Данные не изменятся, а дескриптор часового пояса не изменится задним числом. Для данных этого типа информация не теряется при хранении информации в формате UTC независимо от часового пояса, в котором она была предоставлена. Поэтому удалите часовой пояс.

Future, Long Term Data: Это события, которые либо будут достаточно далеко в будущем, либо будут происходить. Если они хранятся достаточно долго, дескрипторы часовых поясов гарантированно меняются. Хорошим примером данных такого типа является «Еженедельное собрание менеджмента». Это данные, которые вводятся один раз, и ожидается, что они будут работать вечно. Для этих значений важно определить, предоставлены ли они системой или пользователем. Для предоставленных пользователем данных время должно храниться в часовом поясе создателя, иначе все может привести к потере информации. Эта потеря информации становится очевидной, когда меняется определение часового пояса, и время отображается для создателя как имеющее совершенно другое значение!

Как указал Bwooce, существует некоторая путаница, когда создатель и зритель находятся в разных часовых поясах. В этом случае я ожидаю, что приложение укажет, какие значения времени были перемещены из-за смещения часового пояса от их предыдущих местоположений.

Future, Short Term Data: Это данные, которые быстро станут историческими или действительны только в течение короткого периода времени. Примерами могут быть интервальные таймеры, рейтинговые переходы и т. Д. Для этих данных, поскольку вероятность того, что определение изменится между созданием значения и временем, когда оно станет историческим, может оказаться возможной, если отбросить часовой пояс. Однако я обнаружил, что эти значения имеют плохую привычку превращаться в «Будущее, долгосрочные данные».

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

  • Don't store the timezone as an offset, or the full descriptor.

Если вы сохраняете часовой пояс как смещение, что вы будете делать, если часовой пояс изменится? Пройдете ли вы через систему и внесете ли общие изменения в существующие данные? Если вы это сделаете, то теперь вы указали неверные исторические значения. Хорошими примерами этой ошибки являются Oracle и iCal. Oracle хранит информацию о часовом поясе как смещение от UTC, а iCal включает полный дескриптор для создания часового пояса.

  • Do store it as a name.

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

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

В одной организации секретари должны были распечатать календари для своих команд до даты перехода на летнее время, а затем снова распечатать их после изменения. Наконец, они сравнили их и воссоздали все перенесенные встречи. Конечно, они пропустили несколько, и было несколько недель боли, пока старая дата перехода на летнее время не была достигнута, и времена снова стали правильными.

0

Мне нравится хранить в GMT и показывать только относительные ("около 10 секунд назад", "5 месяцев назад"). Пользователям не нужно видеть фактические временные метки для большинства случаев использования.

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

Большинство приложений, тем не менее, легче понять с помощью простого относительного времени.

1

MS Dynamics хранит GMT, а затем на уровне пользователя знает ваш часовой пояс относительно GMT. Затем он отображает элементы в вашем часовом поясе.

Просто подумал, что я добавлю это, поскольку это довольно большая группа в MS, и именно так они решили справиться с этим.

1

Поэтому я провел небольшой эксперимент с сервером MSSQL.

Я создал таблицу и добавил строку с текущим локализованным часовым поясом (Австралия). Затем я изменил дату и время на GMT и добавил еще одну строку.

Даже если эти строки были добавлены с интервалом около 10 секунд, они появляются на сервере SQL с интервалом в 10 часов.

Если ничего другого, это, по крайней мере, говорит мне, что я должен хранить даты в последовательном порядке, что для меня добавляет вес к аргументу для хранения их как GMT.

хранение их со встроенным смещением также может означать 2 столбца, время gmt и выбранное смещение лиц, а не автоматизированный sqlserver одной формы или клиентский компьютер. DevelopingChris
1

Я предпочитаю хранить все с часовым поясом. клиент может решить, каким образом это должно быть представлено позже. моя любимая библиотека для конвертацииPostgreSQL-Database.

1

Посмотрите здесь, w3c отлично справился с ответом на вопрос.

Посмотрите на варианты использования.

http://www.w3.org/TR/timezone/

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

36

Вы должны хранить в UTC - если вы этого не сделаете, ваши исторические отчеты и поведение во время таких вещей, как переход на летнее время, будут ... забавными. Время по Гринвичу - местное время, в зависимости от летнего времени (нет).

Презентация пользователям в разных часовых поясах может стать настоящим мерзавцем, если вы сохраняете местное время. Его легко настроить на локальный, если ваши исходные данные находятся в UTC - просто добавьте смещение пользователя, и все готово!

Джоэл говорил об этом в одном из подкастов (окольным путем) - он сказалхранить ваши данные в максимально возможном разрешении (ищите «точность»), потому что вы всегда можете изменить его, когда он снова погаснет. Вот почему я говорю, что сохраняйте его как UTC, так как местное время необходимо корректировать для тех, кто не находится в этом часовом поясе, и это очень тяжелая работа. И вам необходимо сохранить, например, была ли, например, летняя экономия, когда вы сохраняли время. ЮК.

Часто в базах данных в прошлом я сохранял два - UTC для сортировки, местное время для отображения. Таким образом, ни пользователь, ни компьютер не запутаются.

Теперь, чтобы отобразить: Конечно, вы можете сделать & quot; 3 минуты назад & quot; вещь, но только если вы храните UTC - в противном случае данные, введенные в разных часовых поясах, будут выполнять такие вещи, как отображение «-4 часа назад», что пугает людей. Если вы собираетесь отображать фактическое время, люди любят, чтобы оно отображалось по местному времени, а если данные вводятся в нескольких часовых поясах, вы можете легко это сделать, только если вы сохраняете UTC.

Но, предположим, у вас есть система бронирования, и вы бронируете номер в часовом поясе с DST в 3 часа дня. Когда наступает летнее время, смещение между GMT и часовым поясом комнаты собраний изменяется на один час. Внезапно встреча забронирована в другое время!
Не берите в голову, я не понял, что вы конвертируете время в смещение DST момента, когда произошла встреча, так что оно всегда будет в правильном смещении.
Нет, по Гринвичу нет летнего времени. Если мы педантичны, то UTC не является часовым поясом. GMT основывается на среднем солнечном времени в Гринвиче. UTC основывается на атомном времени (TAI), отрегулированном на целое число секунд (считайте високосные секунды), чтобы оставаться близко к солнечной фазе Земли, хотя они могут отличаться до 0,9 секунды. Вы должны продолжать встречаться в течение довольно нескольких лет, чтобы время вращения Земли значительно изменилось, но вот почему здесь существует сложность.
0

Я обычно просто использую время Unix. не обязательно в будущем, но это работает довольно хорошо.

1

Лично я не вижу никакой причины не хранить все в GMT, а затем использовать локальный часовой пояс пользователей, чтобы отобразить время, которое относится к ним.

Если вы хотите отобразить относительное время, вам, очевидно, все еще нужно время и сделать перевод, но если вы хотите сделать перевод, я думаю, что GMT по-прежнему ваш лучший вариант.

вопрос в том, во сколько автоматизированные процессы используют, когда говорят, скажем, сроки? Вы храните часовой пояс пользователей, как они решили, и используете его во всех коммуникациях? DevelopingChris
0

Даты должны храниться в формате UTC, ЕСЛИ НЕ БУДУТ данные, предоставленные пользователем, и вы НЕ МОЖЕТЕ знать, в каком часовом поясе пользователь предполагал эти данные. Иногда (очень редко) вам нужно просто сохранить часы, минуты, секунды, день, месяц и год компоненты без какого-либо часового пояса, так что вы можете выплюнуть его обратно пользователю. Теперь для новых разработчиков или, если вы не уверены, сохраните UTC, и вы будете на 99% правы.

Но не обманывайте себя, полагая, что это работает 100% времени для всех случаев все время. Это не.

Похожие вопросы