Обработка часовых поясов в хранилище?

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

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

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

Отобразить относительное время "1 минуту назад"?

15.08.2008 04:54:59
13 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

36
6.11.2012 14:00:22
Но предположим, что у вас есть система бронирования, и вы бронируете комнату в часовом поясе с DST в 15:00. Когда происходит DST, смещение между GMT и часовым поясом комнаты собрания изменяется на один час. Внезапно встреча забронирована в другое время!
Joeri Sebrechts 7.07.2009 09:49:43
Не берите в голову, я не понял, что вы конвертируете время в смещение DST к моменту, когда произошла встреча, так что оно всегда будет в правильном смещении.
Joeri Sebrechts 7.07.2009 10:00:46
Нет, по Гринвичу нет летнего времени. Если мы педантичны, то UTC не является часовым поясом. GMT основывается на среднем солнечном времени в Гринвиче. UTC основывается на атомном времени (TAI), отрегулированном на целое число секунд (считайте високосные секунды), чтобы оставаться близко к солнечной фазе Земли, хотя они могут различаться до 0,9 секунды. Вы должны будете продолжать встречаться довольно много лет, чтобы время вращения Земли заметно изменилось, но вот почему здесь существует сложность.
mc0e 20.02.2017 11:43:59

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

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

1
15.08.2008 05:05:56
вопрос в том, сколько времени используют автоматизированные процессы при сообщении, скажем, сроков людям? Вы храните часовой пояс пользователей, как они решили, и используете его во всех коммуникациях?
DevelopingChris 9.07.2009 14:54:07

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

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

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

0
15.08.2008 05:15:29

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

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

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

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

1
15.08.2008 05:23:13
хранение их со встроенным смещением может также означать 2 столбца, время gmt и выбранное смещение лиц, а не автоматизированный sqlserver одной формы или клиентский компьютер.
DevelopingChris 9.07.2009 14:57:41

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

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

1
15.08.2008 05:27:40

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

0
15.08.2008 06:20:14

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

0
16.09.2008 20:26:25

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

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

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

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

Последствия: он перемещается для всех остальных, неожиданно, из-за смены владельцев TZ, но остается «собранием в 10 утра», если речь идет о владельце.

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

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

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

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

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

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

5
24.09.2012 07:45:06
Outlook Mobile запутывается именно из-за этой ошибки поведения. Встречи по телефону меняются, когда я меняю активную зону.
devstuff 23.12.2008 05:13:51
@devstuff - Перемещение встреч при выборе другого часового пояса не соответствует описанию. Описывается, что сам часовой пояс изменился (из-за законодательных изменений в летнем времени) и, следовательно, часовой пояс, в котором первоначально были описаны данные, больше не существует. то есть времена сместились в одном часовом поясе.
Mark 4.10.2013 00:32:10

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

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

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

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

  1. Исторические данные
  2. Будущее, краткосрочные данные
  3. Будущее, долгосрочные данные

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

  1. Система предоставляется
  2. Предоставлено пользователем

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

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

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

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

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

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

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

  • Не храните часовой пояс как смещение или полный дескриптор.

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

  • Храните это как имя.

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

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

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

13
25.09.2008 02:44:22

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

1
16.10.2008 07:13:48

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

Несколько ceveats:

  1. Если время указано только как время настенных часов, и оно является ведущим представлением, то это не абсолютно определенное время. Вы должны (и не можете) конвертировать его в любом представлении GMT. Например, 9:00 каждое утро. Другими словами: это не время (дата).
  2. Если вы сохраняете дату и время будущей встречи, вы должны использовать смещение по Гринвичу, указанное входным часовым поясом и самим моментом времени . Так что если это встреча летом, например, в Западной Европе, это +2: 00, хотя нормальное (зимнее время) смещение составляет +1: 00. Это решит проблему с каландром, о которой упоминал Bwooce.
  3. Конечно, то же самое относится и к использованию правого смещения при преобразовании в GMT, применяется при обратном преобразовании в дату и время в любом конкретном часовом поясе.

К счастью, при правильном использовании тип DateTime (.NET) позаботится обо всех мрачных деталях хранения календарей и т. Д., И все это должно быть очень легко, когда вы знаете, как это работает.

2
2.08.2009 09:58:00

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

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

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

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

1
19.09.2012 11:18:58

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

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

0
22.02.2019 20:24:08