Обработка часовых поясов в устройстве хранения данных?

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

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

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

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

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

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

Таким образом, я выполнил немного эксперимента с сервером MSSQL.

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

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

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

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

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

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

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

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

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

Последствия: Это перемещается для всех остальных, неожиданно, из-за владельцев изменение TZ, но это остается "10:00, встречающееся", что касается владельца.

'2. Как выше, но инвертированный.

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

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

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

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

я должен поверить своему коллеге и другу Jason Pollock для этого понимания. Читайте его представление здесь , и продолжение, обсуждая iCal и VTIMEZONE здесь.

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

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

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

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

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

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

1. Система, Обеспеченная
2. , Пользователь Обеспечил

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

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

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

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

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

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

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

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

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

• Действительно хранят его как имя.

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

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

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

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

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

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

Несколько сеетов:

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

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