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

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

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

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

Отображение относительного времени «1 минут назад»?

13 ответов

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

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

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

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

    Большинство приложений, однако, легче понять с простым относительным временем.

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

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

    Джоэл говорил об этом в одном из подкастов (в обходном пути)-он сказал, чтобы сохранить ваши данные в самом высоком разрешении возможно (поиск ‘fidelity’), потому что вы всегда можете munge его, когда он выходит снова. Вот почему я говорю хранить его в формате UTC, так как местное время вам нужно настроить для тех, кто не находится в этом часовом поясе, и это много тяжелой работы. И вам нужно сохранить, например, действовала ли экономия летнего времени, когда вы хранили время. Гогот.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Последствия: оно двигает для
    все остальные, неожиданно, из-за
    владельцы TZ меняются, но он остается
    «The 10am meeting» as far as the
    владелец обеспокоен.

    ‘2. Как и выше, но наоборот.

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

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

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

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

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

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

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

    Есть определенные преимущества в хранении данных в формате UTC time_t — это один int, позволяющий быстро сортировать и легко хранить.

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

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

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

    1. Обеспеченная Система
    2. Обеспеченный Потребитель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Несколько ceveats:

    1. Если время указано только как
      время настенных часов и это
      ведущее представление, тогда оно
      не совсем определенное время.
      Вы должны (и не можете) конвертировать его
      в любом представлении GMT. E. G. 9: 00
      AM каждое утро. Иначе говоря:
      это не (дата) время.
    2. Если вы
      сохранение даты и времени будущего
      назначение, вы должны использовать
      смещение в GMT, заданное входным сигналом
      часовой пояс и момент времени
      сама
      . Так что если это назначение
      in summer made in winter in E. G.
      Западная Европа, +2: 00,
      allthough the normal (зимнее время)
      смещение + 1: 00. Это разрешит
      проблема с календарем, Bwooce
      упомянутый.
    3. Конечно, то же самое
      это относится к использованию права
      смещение при преобразовании в GMT
      применяется при обратном преобразовании в a
      дата и время в любом конкретном
      Часовой пояс.

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

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

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

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

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

  13. Даты должны храниться в формате UTC, если это не данные, предоставленные пользователем, и вы не можете знать, в каком часовом поясе пользователь хотел, чтобы эти данные были. Иногда (очень редко) вам нужно просто хранить часовые, минутные, вторые, дневные, месячные и годовые компоненты без какого-либо часового пояса, чтобы вы могли выплюнуть его обратно пользователю. Теперь для новых разработчиков или если вы не уверены, храните UTC, и вы будете на 99% правы.

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