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

StackOverflow https://stackoverflow.com/questions/11975

Вопрос

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

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

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

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

Это было полезно?

Решение

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

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

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

'2.То же, что и выше, но наоборот.

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

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

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

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

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

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

Несколько замечаний:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top